Re: despair - comp.os.vms

----=_vm_0011_W9605427041_15238_1190296803 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >How about DCL? > >$ SHOW SYMBOL /LOCAL/ALL > >at the beginning of your code will show all the arguments! In UNIX, the equivalent "DCL" command is: $ env >What is the environment It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort of like the differences in used /SYSTEM on a DEFINE. I believe, though I am not positive, that the idea for LOGICALS in VMS actually came from UNIX. IIRC, I read that in an AT&T Systems Journal a long time ago. Don't take any of that as a cut at VMS, it isn't. -Paul ----=_vm_0011_W9605427041_15238_1190296803--

On Sep 20, 10:00 am, "Paul Raulerson" <p...@raulersons.com> wrote: > >How about DCL? > > >$ SHOW SYMBOL /LOCAL/ALL > > >at the beginning of your code will show all the arguments! > > In UNIX, the equivalent "DCL" command is: > > $ env I don't see how. Example 1: $ TYPE PNS.COM $ SHOW SYMBOL/LOCAL/ALL $ @PNS PARAM1 PARAM2 PARAM3 P1 = "PARAM1" P2 = "PARAM2" P3 = "PARAM3" P4 = "" P5 = "" P6 = "" P7 = "" P8 = "" $ Example 2: bash-2.03$ cat huh $ env bash-2.03$ ls -l huh -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh bash-2.03$ huh bash: ./huh: Permission denied bash-2.03$ Looks pretty different to me! > >What is the environment > > It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort > of like the differences in used /SYSTEM on a DEFINE. > > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. Say what? > > Don't take any of that as a cut at VMS, it isn't. > > -Paul AEF

On 09/20/07 09:00, Paul Raulerson wrote: >> How about DCL? >> >> $ SHOW SYMBOL /LOCAL/ALL >> >> at the beginning of your code will show all the arguments! > > In UNIX, the equivalent "DCL" command is: > > $ env > >> What is the environment > > It is roughly equivalent to LOGICALS under VMS, but has > signficant differences in the way it used and way it interacts > per process. Sort > of like the differences in used /SYSTEM on a DEFINE.> > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. Oh *puh-leeze*. Unix has *NOTHING* even *remotely* similar to logicals. Unix environment variables are closely akin to *symbols*. The concept of "logical" (probably) came from the mainframe world (and then was expanded into what we know and love today. With your mainframe background, I'm really surprised that you haven't noticed the similarity between DCL logicals an JCL library member name specifications that are then used in COBOL FD definitions. (It's been 19 years since I've used a mainframe, so my terminology is probably a bit off.) > Don't take any of that as a cut at VMS, it isn't. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good!

On Sep 20, 10:56 am, AEF <spamsink2...@yahoo.com> wrote: > bash-2.03$ ls -l huh > -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh > bash-2.03$ huh > bash: ./huh: Permission denied > bash-2.03$ > > Looks pretty different to me! Well, it helps if you do it right. "permission denied" is an error. You want "echo $*" instead of "env": $ ls -l test1 -rwxrwxr-x 1 dpm dpm 30 Sep 20 11:38 test1 $ cat test1 echo hello echo $* echo world $ ./test1 hello world $ ./test1 this is a test 'of command line args' hello this is a test of command line args world $ Keeping command-line arguments and aliases in separate namespaces makes sense. ok dpm

On Sep 20, 11:41 am, "David P. Murphy" <dpm_goo...@myths.com> wrote: > On Sep 20, 10:56 am, AEF <spamsink2...@yahoo.com> wrote: > > > bash-2.03$ ls -l huh > > -rw-r--r-x 1 afeldman other 6 Sep 20 10:54 huh > > bash-2.03$ huh > > bash: ./huh: Permission denied > > bash-2.03$ > > > Looks pretty different to me! > > Well, it helps if you do it right. "permission denied" is an error. > > You want "echo $*" instead of "env": > > $ ls -l test1 > -rwxrwxr-x 1 dpm dpm 30 Sep 20 11:38 test1 > $ cat test1 > echo hello > echo $* > echo world > $ ./test1 > hello > > world > $ ./test1 this is a test 'of command line args' > hello > this is a test of command line args > world > $ > > Keeping command-line arguments and aliases in > separate namespaces makes sense. > > ok > dpm Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating how his suggested equivalent doesn't work. Why the "./"? I know it runs things a little differently than without it, but I forget exactly how. AEF

On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2001@yahoo.com> wrote: > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > how his suggested equivalent doesn't work. Why the "./"? I know it > runs things a little differently than without it, but I forget exactly > how. That has to do with the PATH environment variable which tells the shell the order of search. ./ just means current directory -- PL/I for OpenVMS www.kednos.com

On Sep 20, 12:04 pm, AEF <spamsink2...@yahoo.com> wrote: > On Sep 20, 11:41 am, "David P. Murphy" <dpm_goo...@myths.com> wrote: >> Well, it helps if you do it right. "permission denied" is an error. > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > how his suggested equivalent doesn't work. Why the "./"? I know it > runs things a little differently than without it, but I forget exactly > how. Holy . . . just man up and admit you don't know what you're talking about. In fact don't bother posting if your examples don't even work. The truth is that Paul's suggestion _is_ correct --- your ignorance blinded you. "env" or "set" will show all of the environmental variables, which are the closest thing to logical names, while "alias" will show all of aliases, which are the equivalent to symbols. Trying to map concepts between operating systems can be haphazard, so you can't expect a one-on-one relationship on any given topic. For instance, I think unix's separation of command-line arguments and all other tokens is a good idea, unlike DCL's seemingly haphazard P1-P8 symbols. ok dpm

On Sep 20, 12:24 pm, "Tom Linden" <t...@kednos.company> wrote: > On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2...@yahoo.com> wrote: > > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > > how his suggested equivalent doesn't work. Why the "./"? I know it > > runs things a little differently than without it, but I forget exactly > > how. > > That has to do with the PATH environment variable which tells the shell > the order of search. ./ just means current directory > > -- > PL/I for OpenVMSwww.kednos.com There must be something more to it. Aren't you already in the current directory? Is there some way to be somewhere else? You could use SYS $DISK:[] as the same in VMS (as long as you're not a directory such as SYS$STARTUP) to mean "current directory", but few people bother to type it in! (Though typing [] for current directory can in the case of being in SYS$STARTUP be used to refer to the "current directory" instead! But I don't see how that would apply in Unix.) AEF

On Sep 20, 1:23 pm, "David P. Murphy" <dpm_goo...@myths.com> wrote: > On Sep 20, 12:04 pm, AEF <spamsink2...@yahoo.com> wrote: > > > On Sep 20, 11:41 am, "David P. Murphy" <dpm_goo...@myths.com> wrote: > >> Well, it helps if you do it right. "permission denied" is an error. > > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > > how his suggested equivalent doesn't work. Why the "./"? I know it > > runs things a little differently than without it, but I forget exactly > > how. > > Holy . . . just man up and admit you don't know what you're talking > about. > In fact don't bother posting if your examples don't even work. The > truth > is that Paul's suggestion _is_ correct --- your ignorance blinded you. > > "env" or "set" will show all of the environmental variables, which are > the closest thing to logical names, while "alias" will show all of > aliases, > which are the equivalent to symbols. What in tarnation does this have to do with showing the arguments given to a program? His example wasn't supposed to show logical names or symbols; it was supposed to show the arguments given on the command line! In DCL these happen to be the symbols P1..P8. In Unix it's something else. Yes, I know that env shows the environment variables (on a command line at least). So what? The point was to show the arguments given to a program. He said what the equivalent was, I tried it, it didn't work. If there's some secret Unix incantation like the ./ bit and substituting echo $* for env, it should be explained. This is a VMS newsgroup!!! Not Unix. Unix expertise should not be assumed. > Trying to map concepts between > operating systems can be haphazard, so you can't expect a one-on-one > relationship on any given topic. For instance, I think unix's > separation > of command-line arguments and all other tokens is a good idea, unlike > DCL's seemingly haphazard P1-P8 symbols. > > ok > dpm I don't follow your argument. Paul Raulerson wrote: > For example, to print out the command line arguments and environment for a C > program takes the following code; > > #include <stdio.h> > > int main (int argc, char *argv[], char *envp[]) { > > int c; > > for (c=1; c< argc; c++) { > printf ("Argument #%0d: %s\n", c, argv[c]); > } > > c=0; > while (envp[c] != NULL) { > printf ("Env: %s\n", envp[c++]); > } > > } So he said you could list the arguments with the first part of the above code. So I said this is how you do it in DCL: >How about DCL? >$ SHOW SYMBOL /LOCAL/ALL >at the beginning of your code will show all the arguments! Then he said: > In UNIX, the equivalent "DCL" command is: > > $ env I then posted the result of running that in a shell script and showed that it didn't do what Paul said it would. Then you came in and complained that my example didn't work. Of course it didn't work. That was the point! I don't think we're communicating well here. AEF

Paul Raulerson wrote: >>How about DCL? >> >>$ SHOW SYMBOL /LOCAL/ALL >> >>at the beginning of your code will show all the arguments! > > > In UNIX, the equivalent "DCL" command is: > > $ env > > >>What is the environment > > > It is roughly equivalent to LOGICALS under VMS, but has signficant differences in the way it used and way it interacts per process. Sort > of like the differences in used /SYSTEM on a DEFINE. > > I believe, though I am not positive, that the idea for LOGICALS in VMS > actually came from UNIX. IIRC, I read that in an AT&T Systems Journal > a long time ago. <snip> I think that Unix "environment" is a LOT closer to symbols in VMS than it is to logical names. I find VMS symbols a lot easier to work with than Unix environment variables. Doing arithmetic with symbols is certainly easier!

In article <1190309266.107100.248910@50g2000hsm.googlegroups.com>, AEF <spamsink2001@yahoo.com> writes: > On Sep 20, 12:24 pm, "Tom Linden" <t...@kednos.company> wrote: >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2...@yahoo.com> wrote: >> > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating >> > how his suggested equivalent doesn't work. Why the "./"? I know it >> > runs things a little differently than without it, but I forget exactly >> > how. >> >> That has to do with the PATH environment variable which tells the shell >> the order of search. ./ just means current directory >> >> -- >> PL/I for OpenVMSwww.kednos.com > > There must be something more to it. No. There isn't anything more to it. > Aren't you already in the current > directory? Yes. You are. But that doesn't mean that a token that you type at the beginning of a command line is treated as a request to look for like-named file in the current directory and execute it, if found. It is treated as a request to look for a like-named file in your $PATH and execute it, if found. Your current directory may or may not be in your $PATH. One common anti-trojan measure is to ensure that the current directory is not in your $PATH. Just as on VMS, the current default directory is used as a default directory in which files specified with unqualified file names are found or created and as a starting point for locating files specified with relative directory names. (On Unix, relative names are names such as foo/bar.dat or ../../foo/bar.dat and on VMS relative names are names such as [.foo]bar.dat or [--.foo]bar.dat) > Is there some way to be somewhere else? You could use SYS > $DISK:[] as the same in VMS (as long as you're not a directory such as > SYS$STARTUP) to mean "current directory", but few people bother to > type it in! Compare to DCL$PATH. If SYS$DISK:[] is not in DCL$PATH then the existence of FOO.EXE in your default directory will not make "$ FOO BAR" a meaningful DCL command. Same way, if ./ is not in $PATH then the existence of foo in your default directory will not make "csh> foo bar" a meaningful C shell command. > (Though typing [] for current directory can in the case of > being in SYS$STARTUP be used to refer to the "current directory" > instead! But I don't see how that would apply in Unix.) > > AEF >

On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: > In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes: > > > On Sep 20, 12:24 pm, "Tom Linden" <t...@kednos.company> wrote: > >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2...@yahoo.com> wrote: > >> > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > >> > how his suggested equivalent doesn't work. Why the "./"? I know it > >> > runs things a little differently than without it, but I forget exactly > >> > how. > > >> That has to do with the PATH environment variable which tells the shell > >> the order of search. ./ just means current directory > > >> -- > >> PL/I for OpenVMSwww.kednos.com > > > There must be something more to it. > > No. There isn't anything more to it. I once tried to write a cd program in Unix. (Patience, I need to supply background.) Just putting a cd command in a script and then running it didn't work! Running a script apparently creates a new process (forking?), the directory is changed there, then the new process exits leaving you back where you already were. Well how the hell are you supposed to write shell script macros to run a frequently used series of commands if unexpected screwy things like this are likely to happen?! I asked the Unix guys in my group and they said run it so and so in which I vaguely remember that so and so was to run it with ./ in front of it. Mabye I recall that incorrectly. Anyway, I did what they said, but then it broke something else I wanted to do in the cd program. I quickly resigned (may not be the right word here) myself to make due with $OLDPWD until I learned more about shell scripting. > > > Aren't you already in the current > > directory? > > Yes. You are. But that doesn't mean that a token that you type > at the beginning of a command line is treated as a request to > look for like-named file in the current directory and execute it, if > found. > > It is treated as a request to look for a like-named file in your $PATH > and execute it, if found. > > Your current directory may or may not be in your $PATH. One common > anti-trojan measure is to ensure that the current directory is > not in your $PATH. Ah! OK. Got it. > Just as on VMS, the current default directory is used as a default > directory in which files specified with unqualified file names are > found or created and as a starting point for locating files specified > with relative directory names. > > (On Unix, relative names are names such as foo/bar.dat or ../../foo/bar.dat > and on VMS relative names are names such as [.foo]bar.dat or [--.foo]bar.dat) Well, I at least know that much! OK. > > Is there some way to be somewhere else? You could use SYS > > $DISK:[] as the same in VMS (as long as you're not a directory such as > > SYS$STARTUP) to mean "current directory", but few people bother to > > type it in! > > Compare to DCL$PATH. If SYS$DISK:[] is not in DCL$PATH then > the existence of FOO.EXE in your default directory will not > make "$ FOO BAR" a meaningful DCL command. > > Same way, if ./ is not in $PATH then the existence of foo > in your default directory will not make "csh> foo bar" a meaningful > C shell command.> (Though typing [] for current directory can in the case of > > being in SYS$STARTUP be used to refer to the "current directory" > > instead! But I don't see how that would apply in Unix.) OK, but I never use DCL$PATH, even though I have it on my V6.2 systems. I never saw a need for it at my site. > > > AEF AEF

In article <1190312580.941296.293910@19g2000hsx.googlegroups.com>, AEF <spamsink2001@yahoo.com> writes: > On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: >> In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes: >> >> > On Sep 20, 12:24 pm, "Tom Linden" <t...@kednos.company> wrote: >> >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2...@yahoo.com> wrote: >> >> > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating >> >> > how his suggested equivalent doesn't work. Why the "./"? I know it >> >> > runs things a little differently than without it, but I forget exactly >> >> > how. >> >> >> That has to do with the PATH environment variable which tells the shell >> >> the order of search. ./ just means current directory >> >> >> -- >> >> PL/I for OpenVMSwww.kednos.com >> >> > There must be something more to it. >> >> No. There isn't anything more to it. > > I once tried to write a cd program in Unix. (Patience, I need to > supply background.) Just putting a cd command in a script and then > running it didn't work! Running a script apparently creates a new > process (forking?), the directory is changed there, then the new > process exits leaving you back where you already were. Yes indeed. Pretty much the same as if you did a $ SPAWN SET DEF [.FOO] > Well how the > hell are you supposed to write shell script macros to run a frequently > used series of commands if unexpected screwy things like this are > likely to happen?! Unexpected, perhaps. Screwy, not really. Just different. > I asked the Unix guys in my group and they said run it so and so in > which I vaguely remember that so and so was to run it with ./ in front > of it. Mabye I recall that incorrectly. Yes. You do recall that incorrectly. What they actually told you to do was: .. ./scriptname The dot tells your shell to execute the given script in the current shell context rather than in a subshell context. Kind of like an 'include' -- it works pretty much as if you'd pasted the script contents as input to the running shell. According to the documentation for the sh shell, the script referred to is searched for in $PATH. So if you want to use a script in the current default directory, you need to make that explicit. > Anyway, I did what they said, > but then it broke something else I wanted to do in the cd program. I > quickly resigned (may not be the right word here) myself to make due > with $OLDPWD until I learned more about shell scripting. Ok. > >> >> > Aren't you already in the current >> > directory? >> >> Yes. You are. But that doesn't mean that a token that you type >> at the beginning of a command line is treated as a request to >> look for like-named file in the current directory and execute it, if >> found. >> >> It is treated as a request to look for a like-named file in your $PATH >> and execute it, if found. >> >> Your current directory may or may not be in your $PATH. One common >> anti-trojan measure is to ensure that the current directory is >> not in your $PATH. > > Ah! OK. Got it. > >> Just as on VMS, the current default directory is used as a default >> directory in which files specified with unqualified file names are >> found or created and as a starting point for locating files specified >> with relative directory names. >> >> (On Unix, relative names are names such as foo/bar.dat or ../../foo/bar.dat >> and on VMS relative names are names such as [.foo]bar.dat or [--.foo]bar.dat) > > Well, I at least know that much! OK. > >> > Is there some way to be somewhere else? You could use SYS >> > $DISK:[] as the same in VMS (as long as you're not a directory such as >> > SYS$STARTUP) to mean "current directory", but few people bother to >> > type it in! >> >> Compare to DCL$PATH. If SYS$DISK:[] is not in DCL$PATH then >> the existence of FOO.EXE in your default directory will not >> make "$ FOO BAR" a meaningful DCL command. >> >> Same way, if ./ is not in $PATH then the existence of foo >> in your default directory will not make "csh> foo bar" a meaningful >> C shell command.> (Though typing [] for current directory can in the case of >> > being in SYS$STARTUP be used to refer to the "current directory" >> > instead! But I don't see how that would apply in Unix.) > > OK, but I never use DCL$PATH, even though I have it on my V6.2 > systems. I never saw a need for it at my site. Nor do I. If I want to run an executable, I can use "RUN" and if I want to invoke a DCL script I can use "@". I was just trying to explain the Unix behavior in terms that might be comfortable to someone who is more familiar with VMS.

On Thu, 20 Sep 2007 12:18:45 -0700, <briggs@encompasserve.org> wrote: > According to the documentation for the sh shell, the script referred > to is searched for in $PATH. So if you want to use a script in > the current default directory, you need to make that explicit. Perhaps it is wise to add a caveat here. when you issue a command, say $ foo The directories are searched, left to right in the PATH list and it will execute the first one it encounters. To determine which one it is you could $ which foo -- PL/I for OpenVMS www.kednos.co

On Thu, 20 Sep 2007 10:43:07 -0700, AEF <spamsink2001@yahoo.com> wrote: > If there's some secret Unix incantation like the ./ bit and > substituting echo $* for env, it should be explained. This is a VMS > newsgroup!!! Not Unix. Unix expertise should not be assumed. REX> sho sym echo ECHO =3D=3D "WRITE SYS$OUTPUT " -- = PL/I for OpenVMS www.kednos.com

In article <op.tyy0kuwuhv4qyg@murphus>, "Tom Linden" <tom@kednos.company> writes: > > >On Thu, 20 Sep 2007 10:43:07 -0700, AEF <spamsink2001@yahoo.com> wrote: > >> If there's some secret Unix incantation like the ./ bit and >> substituting echo $* for env, it should be explained. This is a VMS >> newsgroup!!! Not Unix. Unix expertise should not be assumed. > >REX> sho sym echo > ECHO =3D=3D "WRITE SYS$OUTPUT " Nor should quoted-printable decoding. The above: ECHO = 3D = 3D "WRITE SYS$OUTPUT " makes much more sense to somebody reading this if the = 3D is elided by posting in plain text. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html

On Thu, 20 Sep 2007 14:44:55 -0700, VAXman- <@SendSpamHere.ORG> wrote: > In article <op.tyy0kuwuhv4qyg@murphus>, "Tom Linden" = > <tom@kednos.company> writes: >> >> >> On Thu, 20 Sep 2007 10:43:07 -0700, AEF <spamsink2001@yahoo.com> wrot= e: >> >>> If there's some secret Unix incantation like the ./ bit and >>> substituting echo $* for env, it should be explained. This is a VMS >>> newsgroup!!! Not Unix. Unix expertise should not be assumed. >> >> REX> sho sym echo >> ECHO =3D3D=3D3D "WRITE SYS$OUTPUT " > > Nor should quoted-printable decoding. The above: > > ECHO =3D 3D =3D 3D "WRITE SYS$OUTPUT " > > makes much more sense to somebody reading this if the =3D 3D is elided= > by posting in plain text. > But I thought I did post in plain text. I just checked my encoding and = it = is set to ISO-8859-15, of course with Windows I suppose anything can happen= .. = I have recently discovered that if I choose Firefox Outlook stops decoding HTML mail and= = prefixes the TO: field with %smtp. most vexing. So then I get out of Firefox launch= = Opera make it my default when asked, then when launching Outlook make it default for = mail when asked. Grrr. -- = PL/I for OpenVMS www.kednos.com

On Sep 20, 3:18 pm, bri...@encompasserve.org wrote: > In article <1190312580.941296.293...@19g2000hsx.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes: > > > > > On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: > >> In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes: > > >> > On Sep 20, 12:24 pm, "Tom Linden" <t...@kednos.company> wrote: > >> >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF <spamsink2...@yahoo.com> wrote: > >> >> > Tell that to Paul Raulerson. It wasn't my idea. I was demonstrating > >> >> > how his suggested equivalent doesn't work. Why the "./"? I know it > >> >> > runs things a little differently than without it, but I forget exactly > >> >> > how. > > >> >> That has to do with the PATH environment variable which tells the shell > >> >> the order of search. ./ just means current directory > > >> >> -- > >> >> PL/I for OpenVMSwww.kednos.com > > >> > There must be something more to it. > > >> No. There isn't anything more to it. > > > I once tried to write a cd program in Unix. (Patience, I need to > > supply background.) Just putting a cd command in a script and then > > running it didn't work! Running a script apparently creates a new > > process (forking?), the directory is changed there, then the new > > process exits leaving you back where you already were. > > Yes indeed. Pretty much the same as if you did a $ SPAWN SET DEF [.FOO] > > > Well how the > > hell are you supposed to write shell script macros to run a frequently > > used series of commands if unexpected screwy things like this are > > likely to happen?! > > Unexpected, perhaps. Screwy, not really. Just different. > > > I asked the Unix guys in my group and they said run it so and so in > > which I vaguely remember that so and so was to run it with ./ in front > > of it. Mabye I recall that incorrectly. > > Yes. You do recall that incorrectly. > > What they actually told you to do was: > > . ./scriptname > > The dot tells your shell to execute the given script in the current > shell context rather than in a subshell context. Kind of like an > 'include' -- it works pretty much as if you'd pasted the script > contents as input to the running shell. > > According to the documentation for the sh shell, the script referred > to is searched for in $PATH. So if you want to use a script in > the current default directory, you need to make that explicit. > > > Anyway, I did what they said, > > but then it broke something else I wanted to do in the cd program. I > > quickly resigned (may not be the right word here) myself to make due > > with $OLDPWD until I learned more about shell scripting. > > Ok. > > > > > > >> > Aren't you already in the current > >> > directory? > > >> Yes. You are. But that doesn't mean that a token that you type > >> at the beginning of a command line is treated as a request to > >> look for like-named file in the current directory and execute it, if > >> found. > > >> It is treated as a request to look for a like-named file in your $PATH > >> and execute it, if found. > > >> Your current directory may or may not be in your $PATH. One common > >> anti-trojan measure is to ensure that the current directory is > >> not in your $PATH. > > > Ah! OK. Got it. > > >> Just as on VMS, the current default directory is used as a default > >> directory in which files specified with unqualified file names are > >> found or created and as a starting point for locating files specified > >> with relative directory names. > > >> (On Unix, relative names are names such as foo/bar.dat or ../../foo/bar.dat > >> and on VMS relative names are names such as [.foo]bar.dat or [--.foo]bar.dat) > > > Well, I at least know that much! OK. > > >> > Is there some way to be somewhere else? You could use SYS > >> > $DISK:[] as the same in VMS (as long as you're not a directory such as > >> > SYS$STARTUP) to mean "current directory", but few people bother to > >> > type it in! > > >> Compare to DCL$PATH. If SYS$DISK:[] is not in DCL$PATH then > >> the existence of FOO.EXE in your default directory will not > >> make "$ FOO BAR" a meaningful DCL command. > > >> Same way, if ./ is not in $PATH then the existence of foo > >> in your default directory will not make "csh> foo bar" a meaningful > >> C shell command.> (Though typing [] for current directory can in the case of > >> > being in SYS$STARTUP be used to refer to the "current directory" > >> > instead! But I don't see how that would apply in Unix.) > > > OK, but I never use DCL$PATH, even though I have it on my V6.2 > > systems. I never saw a need for it at my site. > > Nor do I. If I want to run an executable, I can use "RUN" and > if I want to invoke a DCL script I can use "@". > > I was just trying to explain the Unix behavior in terms that might be > comfortable to someone who is more familiar with VMS. OK. Thanks for the explanation! AEF

In article <aPQ8qb2bL0n0@eisner.encompasserve.org>, briggs@encompasserve.org writes: > > What they actually told you to do was: > > . ./scriptname > > The dot tells your shell to execute the given script in the current > shell context rather than in a subshell context. Kind of like an > 'include' -- it works pretty much as if you'd pasted the script > contents as input to the running shell. Of course, you're assuming which shell the fellow was using.