f



Finding directory file of current directory

Ok, I know how to use F$ENVIRONMENT and F$PARSE to get the current
directory specification of where a command procedure lives.

I know I can use SET DIR dev:[dir.dir.dir]/OWNER=new_owner

But SET DIR doesn't support /PROT

and SET SECURITY doesn't seem to support directory specifications.

Is there a magic incantation that would allow me to set the protection
on the directory file of the current working directory (eg: the .DIR
file one level above) ?

Breaking the directory specification apart to build a file name seems
more involved, especially if you need to support both:

CAKE:[chocolate]    (which would translate to  CAKE:[000000]chocolate.dir

as well as

$DISK2:[FOOD.RECIPES.CAKE.CHOCOLATE] which translate to $DISK2:[FOOD.RECIPES.CAKE]chocolate.dir
0
9/14/2005 11:00:36 AM
comp.os.vms 21904 articles. 1 followers. Post Follow

17 Replies
773 Views

Similar Articles

[PageSpeed] 3

In article <432802AA.62A4F106@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
> Ok, I know how to use F$ENVIRONMENT and F$PARSE to get the current
> directory specification of where a command procedure lives.
> I know I can use SET DIR dev:[dir.dir.dir]/OWNER=new_owner
> But SET DIR doesn't support /PROT
> and SET SECURITY doesn't seem to support directory specifications.
> Is there a magic incantation that would allow me to set the protection
> on the directory file of the current working directory (eg: the .DIR
> file one level above) ?
> Breaking the directory specification apart to build a file name seems
> more involved, especially if you need to support both:
> CAKE:[chocolate]    (which would translate to  CAKE:[000000]chocolate.dir
> as well as
> $DISK2:[FOOD.RECIPES.CAKE.CHOCOLATE] which translate to $DISK2:[FOOD.RECIPES.CAKE]chocolate.dir

Not knowing a magic incantation, it should be straight to use 
f$element(n,".",mydir) to get the last part of the directory string.
And it doesn't matter if it's in the [000000] root or not, one can
replace [something] by [000000.something].
For ODS2 volumes such a DCL procedure is easy to write. For ODS5 
volumes with multiple dots allowed in file names, it becomes a bit more
complicated.
 
But to what purpose should a procedure want to do that ? If it wants 
to write in a write-protected directory, then probably redirecting to
sys$scratch: would be a cleaner solution

-- 
   Joseph Huber , Muenchen,Germany:  http://www.huber-joseph.de/
0
huber7 (61)
9/14/2005 1:41:48 PM
HP (John Gillings?)  Could we please get support for F$ELEMENT(-n,...)
added to DCL?  Then it would be easier to pick off the LAST element of
a list.   In the same spirit as <filename>;-n

Here's a command procedure I wrote years ago to handle the issue:

$! uponedir.com -- find previous level in directory tree
$!                 return value to global symbol 'p2'
$! parameters
$! p1 -- input directory
$! p2 -- output directory
$! p3 -- if present -- gets current dir dirfile spec
$  vfl = f$ver(0)
$  save_dir = f$parse("")-".;"
$  if p1.eqs."" then p1 = save_dir
$  set default 'p1'
$  prev_dir_lev = f$parse("[-]")-".;"
$  if prev_dir_lev .eqs."" then  -
$       prev_dir_lev = f$log(f$parse("",,,"device")-":")-".]"-".>"+"]"
$ if p2.nes.""
$ then  $ 'p2' == prev_dir_lev
$ else  $ show sym prev_dir_lev
$ endif
$ cur_dir = f$parse("",,,"DIRECTORY")
$ prev_dir = f$parse(prev_dir_lev,,,"DIRECTORY")
$ if f$Loc(prev_dir-"]",cur_dir).lt.f$len(cur_dir) then $ goto
not_rooted
$  cur_dir_spec = prev_dir_lev+(cur_dir-"["-"]"-"<"-">")+".DIR"
$  goto cur_dir_spec
$ not_rooted:
$  cur_dir_spec =
prev_dir_lev+(cur_dir-(prev_dir-"]"-">")-"]"-">"-".")+".DIR"
$ cur_dir_spec:
$  if p3.eqs."" then $ show sym cur_dir_spec
$  if p3.nes."" then $ 'p3' == cur_dir_spec
$ exit:
$  set default 'save_dir'
$  vfl = f$ver(vfl)
$  exit
$!Last Modified:  14-FEB-1994

See if that solves your problem.

Robert

0
bob200 (48)
9/14/2005 2:52:59 PM
In message <1126709579.823272.72450@o13g2000cwo.googlegroups.com>,
 "R Boyd" <bob@hax.com> writes:
>HP (John Gillings?)  Could we please get support for F$ELEMENT(-n,...)
>added to DCL?  Then it would be easier to pick off the LAST element of
>a list.   In the same spirit as <filename>;-n

While you're at it, how about supporting f$parse(spec,,,"DEVICE+DIRECTORY") or
f$parse(spec,,,"NAME+TYPE")?


David L. Jones               |      Phone:    (614) 271-6718
Ohio State University        |      Internet:
140 W. 19th St.              |               jonesd@er6s1.eng.ohio-state.edu
Columbus, OH 43210           |               vman+@osu.edu

Disclaimer: I'm looking for marbles all day long.
0
JONESD2 (40)
9/14/2005 3:25:29 PM
Good ideas.  I'll log them on our internal systems.

Jilly

"David Jones" <JONESD@ecr6.ohio-state.edu> wrote in message 
news:dg9fd9$10n$1@charm.magnus.acs.ohio-state.edu...
> In message <1126709579.823272.72450@o13g2000cwo.googlegroups.com>,
> "R Boyd" <bob@hax.com> writes:
>>HP (John Gillings?)  Could we please get support for F$ELEMENT(-n,...)
>>added to DCL?  Then it would be easier to pick off the LAST element of
>>a list.   In the same spirit as <filename>;-n
>
> While you're at it, how about supporting 
> f$parse(spec,,,"DEVICE+DIRECTORY") or
> f$parse(spec,,,"NAME+TYPE")?
>
>
> David L. Jones               |      Phone:    (614) 271-6718
> Ohio State University        |      Internet:
> 140 W. 19th St.              | 
> jonesd@er6s1.eng.ohio-state.edu
> Columbus, OH 43210           |               vman+@osu.edu
>
> Disclaimer: I'm looking for marbles all day long. 


0
jilly2 (84)
9/14/2005 4:39:53 PM
Joseph Huber wrote:
> But to what purpose should a procedure want to do that ? If it wants
> to write in a write-protected directory, then probably redirecting to
> sys$scratch: would be a cleaner solution


Unpack a zip file into a directory such as dev:[chocolate]. In it is a
command procedure to complete installation, and it needs to set 
ownership and protection on the chocolate.dir file sitting above the
current directory.
0
9/15/2005 12:13:54 AM
JF Mezei wrote:
> Joseph Huber wrote:
> 
>>But to what purpose should a procedure want to do that ? If it wants
>>to write in a write-protected directory, then probably redirecting to
>>sys$scratch: would be a cleaner solution
> 
> 
> 
> Unpack a zip file into a directory such as dev:[chocolate]. In it is a
> command procedure to complete installation, and it needs to set 
> ownership and protection on the chocolate.dir file sitting above the
> current directory.

Maybe I'm missing something here, which wouldn't be unusual, but what's 
wrong with:

SET PROT=W:RE [-]chocolate.dir

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      Fax: 724-529-0596
DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA  15486
0
davef3 (3716)
9/15/2005 1:12:35 AM
JF Mezei wrote:
> Joseph Huber wrote:
> 
>>But to what purpose should a procedure want to do that ? If it wants
>>to write in a write-protected directory, then probably redirecting to
>>sys$scratch: would be a cleaner solution
> 
> 
> 
> Unpack a zip file into a directory such as dev:[chocolate]. In it is a
> command procedure to complete installation, and it needs to set 
> ownership and protection on the chocolate.dir file sitting above the
> current directory.

Do you know for sure the zip file will unzip into a sub-tree with
"chocolate" at the top level?  I.E. where ever the person doing the
installation decides to put it, the install command file will be
some_dev:[something...chocolate]install.com?

Have install.com remember the current default dev: and directory,
then get its current dev: and directory (I'm pretty sure
you can get all this info with lexicals) and set default to it.
Then install.com should be able to
   $ set file/owner=.../prot=(...) [-]chocolate.dir
   $ set file/owner=.../prot=(...) [...]*.*;*"

At the end of install.com, set default back to the saved dev/directory.

By using self-relative file specs, you should avoid having to parse
anything, which is 99% of the battle.

Or package it up to use PCSI :-) :-)


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
0
john5 (550)
9/15/2005 1:15:59 AM
John Santos wrote:
> Do you know for sure the zip file will unzip into a sub-tree with
> "chocolate" at the top level? 

Nop. That is the problem. The install procedure doesn't know the name of
the current directory level. It can get the full directory spec from
F$environment(). So it is a question of parsing its contents.

> Or package it up to use PCSI :-) :-)

PCSI, last time I looked, PCSI sucked for anything more than a glorified
UNZIP. The point of my install is to run real DCL , ask questions etc.
With PCSI, you can't run real DCL, it runs under a subprocess without
assurance that output will be seen by user, nor that prompting will be supported.
0
9/15/2005 1:40:05 AM
Jilly wrote:
> "David Jones" <JONESD@ecr6.ohio-state.edu> wrote in message
> news:dg9fd9$10n$1@charm.magnus.acs.ohio-state.edu...
> > In message <1126709579.823272.72450@o13g2000cwo.googlegroups.com>,
> > "R Boyd" <bob@hax.com> writes:
> >>HP (John Gillings?)  Could we please get support for F$ELEMENT(-n,...)
> >>added to DCL?  Then it would be easier to pick off the LAST element of
> >>a list.   In the same spirit as <filename>;-n
> >
> > While you're at it, how about supporting
> > f$parse(spec,,,"DEVICE+DIRECTORY") or
> > f$parse(spec,,,"NAME+TYPE")?
> >
> >
> > David L. Jones               |      Phone:    (614) 271-6718
> > Ohio State University        |      Internet:
> > 140 W. 19th St.              |
> > jonesd@er6s1.eng.ohio-state.edu
> > Columbus, OH 43210           |               vman+@osu.edu
> >
> > Disclaimer: I'm looking for marbles all day long.
> 
> Good ideas.  I'll log them on our internal systems.

Then, I'll add my $0.02...

How 'bout adding:

$ X = F$PARSE( "SYS$STARTUP:SYSTARTUP_VMS.COM",,,, -
		"NO_TRANSLATE,SYNTAX_ONLY" )

....so the DIRECTORY item would return a null string, and the DEVICE item
would return "SYS$STARTUP:" instead of "SYS$SYSROOT:" for the DEVICE and
"[SYS$STARTUP]" for the DIRECTORY (SYSTARTUP_VMS.COM usually doesn't
live there, though I suppose its possible).

I also like the idea of being able to return multiple items in a single
invocation:

$ path := device,directory
$ floc = f$parse( filespec,,, path )

....or perhaps negate what you don't want returned and get the rest in a
single call:

$ fsp = f$parse( filespec,,, "nodevice,nodirectory" )

(No, I *WON'T* tell what I'm on, and no, you can't have any! ;-)

-- 
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Coming soon:
Unofficial OpenVMS Marketing Home Page
0
9/15/2005 2:24:54 AM
JF Mezei wrote:
> 
> John Santos wrote:
> > Do you know for sure the zip file will unzip into a sub-tree with
> > "chocolate" at the top level?
> 
> Nop. That is the problem. The install procedure doesn't know the name of
> the current directory level.

Then, I might infer that the installation creates the target directory,
if it's missing, in which case I would suggest using, for example:

$ CREATE/DIRECT [.CHOCOLATE]/PROT=mask/OWN=owner_uic

However, if the directory already exists, changing the security of an
existing path might be a brash assumption.

> It can get the full directory spec from
> F$environment(). So it is a question of parsing its contents.

Again, assuming you're thinking of F$ENVI( "DEFAULT" ), yes, that would
be true.

> 
> > Or package it up to use PCSI :-) :-)
> 
> PCSI, last time I looked, PCSI sucked for anything more than a glorified
> UNZIP. The point of my install is to run real DCL , ask questions etc.
> With PCSI, you can't run real DCL, it runs under a subprocess without
> assurance that output will be seen by user, nor that prompting will be supported.

Didn't Didier whip up a PCSI "cookbook"? Anyone have a link?

-- 
David J Dachtera
dba DJE Systems
http://www.djesys.com/

Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/

Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/

Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/

Coming soon:
Unofficial OpenVMS Marketing Home Page
0
9/15/2005 2:32:02 AM
JF Mezei wrote:
> John Santos wrote:
> 
>>Do you know for sure the zip file will unzip into a sub-tree with
>>"chocolate" at the top level? 
> 
> 
> Nop. That is the problem. The install procedure doesn't know the name of
> the current directory level. It can get the full directory spec from
> F$environment(). So it is a question of parsing its contents.
> 
> 
>>Or package it up to use PCSI :-) :-)
> 
> 
> PCSI, last time I looked, PCSI sucked for anything more than a glorified
> UNZIP. The point of my install is to run real DCL , ask questions etc.
> With PCSI, you can't run real DCL, it runs under a subprocess without
> assurance that output will be seen by user, nor that prompting will be supported.

Ok, my DCL is a bit rusty, and I have no ODS-5 experience, never yet 
found a reason to use ODS-5, but the following is a short proof of concept:

DFE90A::DFEUL> t x.com
$$ wso :== write SYS$OUTPUT
$
$ CurDir :== 'F$DIRECTORY()
$ wso "The current directory path is: ''CurDir'"
$
$ set default [-]
$ TopDir :== 'F$DIRECTORY()
$ wso "The directory path up one level is: ''TopDir'"
$
$ set default 'CurDir
$
$ X1 = F$LENGTH(TopDir)
$ X2 = F$LENGTH(CurDir) - X1 - 1
$
$ ThisDir :== 'F$EXTRACT(X1,X2,CurDir)
$ wso "The name of the current directory file is: ''ThisDir'"
DFE90A::DFEUL> @x
The current directory path is: [DFEUL.DETACH]
The directory path up one level is: [DFEUL]
The name of the current directory file is: DETACH

Should work with both '[' and '<'.  Haven't done any serious testing.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      Fax: 724-529-0596
DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA  15486
0
davef3 (3716)
9/15/2005 3:42:36 AM
Dave Froble wrote:
> $ X1 = F$LENGTH(TopDir)
> $ X2 = F$LENGTH(CurDir) - X1 - 1
> $
> $ ThisDir :== 'F$EXTRACT(X1,X2,CurDir)
> $ wso "The name of the current directory file is: ''ThisDir'"
> DFE90A::DFEUL> @x
> The current directory path is: [DFEUL.DETACH]
> The directory path up one level is: [DFEUL]
> The name of the current directory file is: DETACH


I was thinking along those lines too. However, the above is not perfect.

if current directory is  DEV:[PIE]

set DEF [.-] makes current directory : DEV:[000000]

The lengths can't be used to isolate the difference between the upper
and current dirs especially since in my example, the length of the
current directory is shorter than the length of its parent directory :-)

However, this might be mitigated by testing for [000000] in the parent directory.


I was hoping there was a simple magic incantation that would solve my
problem. But I guess not. 

Also CREATE/DIR will not apply owner and protection on an existing
directory. So even if my installation procedure insists on creating its
own directory structure, there is no assurance that this directory will
bear the attributes that are desired.


If SET DIRECTORY command had /PROT , it would have made my life much
easier (it already has /OWNER).
0
9/15/2005 5:26:40 AM
In article <4328BCC2.21BEBD42@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
> Joseph Huber wrote:
>> But to what purpose should a procedure want to do that ? If it wants
>> to write in a write-protected directory, then probably redirecting to
>> sys$scratch: would be a cleaner solution
> 
> Unpack a zip file into a directory such as dev:[chocolate]. In it is a
> command procedure to complete installation, and it needs to set 
> ownership and protection on the chocolate.dir file sitting above the
> current directory.

But this situation should not be handled by an automatic procedure,
but by the human/administrator doing the installation beforehand 
(after exiting the procedure with an appropriate error message),
it is his/her fault anyhow to try it, and probably not indended.
 
-- 
   Joseph Huber , Muenchen,Germany:  http://www.huber-joseph.de/
0
huber7 (61)
9/15/2005 7:16:51 AM
Joseph Huber wrote:
> But this situation should not be handled by an automatic procedure,
> but by the human/administrator doing the installation beforehand
> (after exiting the procedure with an appropriate error message),
> it is his/her fault anyhow to try it, and probably not indended.


Logically yes. But it is still more professional looking if the
installation procedure can take care of everything in one smooth
sequential uninterrupted operation with the fewest possible manual tasks
required before or worse, during installation.

In some cases, it is easier to implement DCL code to do something than
to document what needs to be manually done and hope the system manager
actually reads the installation manual.
0
9/15/2005 7:44:31 AM
JF Mezei wrote:
> 

> I was hoping there was a simple magic incantation that would solve my
> problem. But I guess not.

In simple magic incantation notation:

$ dir_fn = f$parse("[-]"+("*"+(f$parse("[]",,,"DIRECTORY")+"*"-"]*") -
         -(f$parse("[-]",,,"DIRECTORY")+"*"-"]*")-"*."-"*[")+".DIR")

dir_fn might be "" for a current directory of [000000] or some other
reason.

:-)

0
9/15/2005 12:57:08 PM
JF Mezei wrote:
> 

> I was hoping there was a simple magic incantation that would solve my
> problem. But I guess not.

After thinking about the "right way" to do it I remembered
F$FID_TO_NAME,
assuming there's at least one file in the current directory:

$ fn = f$search("*.*;*")
$ dir_fn = f$fid_to_name(fn, f$file_attributes(fn, "DID") )

But F$FID_TO_NAME is a recent (?8.2) feature, prior to that it would
probably involve a DUMP.

0
9/15/2005 5:44:36 PM
David J Dachtera wrote:
> Jilly wrote:
> > "David Jones" <JONESD@ecr6.ohio-state.edu> wrote in message
[...]
> >
> > Good ideas.  I'll log them on our internal systems.
>
> Then, I'll add my $0.02...
>
> How 'bout adding:
>
> $ X = F$PARSE( "SYS$STARTUP:SYSTARTUP_VMS.COM",,,, -
> 		"NO_TRANSLATE,SYNTAX_ONLY" )
>
> ...so the DIRECTORY item would return a null string, and the DEVICE item
> would return "SYS$STARTUP:" instead of "SYS$SYSROOT:" for the DEVICE and
> "[SYS$STARTUP]" for the DIRECTORY (SYSTARTUP_VMS.COM usually doesn't
> live there, though I suppose its possible).


David,

Try this:

$ WRITE SYS$OUTPUT F$PARSE("0::SYS$STARTUP:SYSTARTUP_VMS.COM")
0::SYS$STARTUP:SYSTARTUP_VMS.COM;

NOTE 1: You don't need DECnet running to have 0:: work, at least not in
this sense.

NOTE 2: This doesn't check for the existence of the specified
directory, but you can do that in a separate call without the "0::".

[...]

0
spamsink2001 (3130)
10/11/2005 7:28:58 PM
Reply: