INFO-VAX Fri, 21 Sep 2007 Volume 2007 : Issue 515 Contents: Re: Command fails in batch, seems to work at-ed interactively Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Xyplex Terminal Server with VMS ---------------------------------------------------------------------- Date: Thu, 20 Sep 2007 17:40:26 -0700 From: AEF Subject: Re: Command fails in batch, seems to work at-ed interactively Message-ID: <1190335226.816314.273460@k79g2000hse.googlegroups.com> On Sep 20, 9:39 am, norm.raph...@metso.com wrote: > AEF wrote on 09/19/2007 08:23:02 PM: > > > > > On Sep 19, 8:19 pm, David J Dachtera > > wrote: > > > AEF wrote: > > > > > On Sep 17, 9:33 pm, Doug Phillips wrote: > > > > > On Sep 17, 8:26 pm, David J Dachtera > > > > > wrote: > > > > > > > Doug Phillips wrote: > > > > > > > > On Sep 17, 11:45 am, norm.raph...@metso.com wrote: > > > > > > > > This code checks for an empty or blanked PostalZip field. > > > > > > > > When run inside the batch, is seems to give a > different,incorrect > > > > > > > > result then when the code is extracted to another procedure > file > > > > > > > > and run against the renamed data file. > > > > > > > > In this case there is a match and Sever is "1". > > > > > > > > In the nomatch case Sever is "3". > > > > > > > > Here the "no strings matched" sets Sever to "3" indicating a > wrong > > > > > > > > result as there should have been a match. > > > > > > > > Why would the same code fail to work and later work on the > renamed > > > > > > > > file. (The diff command is to eliminate the trailing > > spaces first.) > > > > > > > > [OpenVMS Alpha V7.3-1] > > > > > > > > === Actual log excerpt: > > > > > > > > Sent file JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML.1, 571384 > bytes. > > > > > > > > QUIT > > > > > > > > <221 > > > > > > > > $@mfgcom:check_postal.com "JAM317:[CM_PROD.DATA] > > FRONTIER_ATO.XML;1;" > > > > > > > > $!$ ffile="jamdata:FRONTIER_SHR.XML_2007090603045085;1" > > > > > > > > $ > > > > > > > > ffile=f$search(f$parse("JAMDATA:FRONTIER_SHR. > > XML_*;",,,,"SYNTAX_ONLY"),3) > > > > > > > > $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA] > > FRONTIER_ATO.XML;1;" > > > > > > > > $ pipe diff/igno=trail JAM317:[CM_PROD.DATA] > > FRONTIER_ATO.XML;1; nl: > > > > > > > > Is the semicolon ";" *after* the version (i.e. .XML;1;) a > > posting typo > > > > > > > or is it really in your command? > > > > > > > Interesting thought; however, ... > > > > > > > DJAS02::DDACHTERA$ pipe diff/nonumb/igno=trail login.com;1; nl: > > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of > > special characters > > > > > > \;NL\ > > > > > > DJAS02::DDACHTERA$ sh sym $status > > > > > > $STATUS == "%X00038110" > > > > > > > (VMS V7.3-2, V7.2-2 gives same result interactively.) > > > > > > > Gives a different message/status. > > > > > > Yes it does. It pipes the error to the next command, but it > doesn't > > > > > display it. The $status is from the last command in the pipe, no? > > > > > Apparently so! See below. > > > > > Try > > > > > piping it your example. Here's mine: > > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | type sys$pipe > > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > > > characters > > > > > \;NL\ > > > > > .TEST>pipe diff/ignor=trail test.fil;1; nl: /nonum | search > sys$pipe > > > > > "whatever" > > > > > %SEARCH-I-NOMATCHES, no strings matched > > > > > Yes, this extra semicolon appears to be the cause of the problem: > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE SET > > > > %SEARCH-I-NOMATCHES, no strings matched > > > > $ PIPE DIFF LOGIN.COM;4 NL: | SEAR SYS$PIPE SET > > > > 2 $ set noon > > > > 7 $ set terminal/inquire/noeightbit/INSERT/FORM > > > > $ > > > > > Apparently, errors in the first steps aren't reported to SYS$ERROR > or > > > > SYS$ERROR isn't the screen until the last command is run (deja vu: > why > > > > is this only a warning?!): > > > > > $ PIPE DIFF LOGIN.COM;4; NL: | SEAR SYS$PIPE invalid > > > > %DCL-W-PARMDEL, invalid parameter delimiter - check use of special > > > > characters > > > > $ > > > > > This looks like a good reason _not_ to use PIPE in a command > > > > procedure. In this case it saves you from working with temporary > files > > > > and their cleanup but makes troubleshooting more difficult. Friendly > > > > comments welcome on this. > > > > I wouldn't go quite that far. Yes it complicates debugging; however > see: > > > $ HELP PIPE Description Pipelines_and_TEEs Using_TEEs_and_SYS$PIPE > > > > ...for an example of TEE.COM that you can insert into the pipeline and > see > > > what's actually being PIPEd into SEARCH, in this case. > > > > $ PIPE DIFF LOGIN.COM;4; NL: | @TEE SYS$COMMAND | SEAR SYS$PIPE SET > > > > Probably only works on-line. In batch, send the TEE output to a disk > file. > > > > -- > > > David J Dachtera > > > dba DJE Systemshttp://www.djesys.com/ > > > > Unofficial OpenVMS Marketing Home > > Pagehttp://www.djesys.com/vms/market/ > > > > Unofficial Affordable OpenVMS Home > > Page:http://www.djesys.com/vms/soho/ > > > > Unofficial OpenVMS-IA32 Home Page:http://www.djesys.com/vms/ia32/ > > > > Unofficial OpenVMS Hobbyist Support > > Page:http://www.djesys.com/vms/support/ > > > OK, thanks. > > > AEF > > Points taken, but in this case (I covered myself with the "seems" in the > subject) > the debugging problem was "old eyes" as I failed to see the typo-induced > extra > ";" from the calling procedure, so none of these issues would have helped > bring > to light the problem in a "test" scenerio; the real problem, not being > understood, > was not presented to the testing. But what about this: Here's the relevant log snippet: $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML; 1;" $ pipe diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl: /nonumb | - sear sys$pipe ""/window=(0,6)/mat=or/exact/nonumb | - sear sys$pipe "" /exact/nonumb | - sear sys$pipe "> ","><"/exact/out=nl: %SEARCH-I-NOMATCHES, no strings matched Now, suppose instead of using PIPE you did this: $ if p1 .nes. "" then ffile="JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML; 1;" $ diff/igno=trail JAM317:[CM_PROD.DATA]FRONTIER_ATO.XML;1; nl: /nonumb The error message from the DIFF would tell you right away what the problem was, no? AEF ------------------------------ Date: Thu, 20 Sep 2007 14:07:20 -0400 From: "Richard B. Gilbert" Subject: Re: despair Message-ID: <46F2B6D8.9030406@comcast.net> Doug Phillips wrote: > On Sep 20, 6:06 am, b...@cs.uofs.edu (Bill Gunshannon) wrote: > >>In article <46F1AC1A.4000...@comcast.net>, >> "Richard B. Gilbert" writes: >> >> >>>Bob Koehler wrote: >>> >>>>In article <5lahrdF7ce1...@mid.individual.net>, b...@cs.uofs.edu (Bill Gunshannon) writes: >>> >>>>>You new here? There has been a long running (more than a decade at >>>>>least) notion here that it is either the Operating System or the >>>>>langauge that makes for bad programs. Unix and C are at the top of >>>>>the list. >>>> >>>> Really? And all this time I thought was both. >>> >>>Unix and C both HELP to make bad programs. >> >>Bullcrap. >> >> >>> What's REALLY responsible >>>for bad programs is usually bad programmers. >> >>Not usually, always. >> > > > Inexperienced != Bad. Without knowing the programmer, I would only say > that it's bad code. Bad programmers have written good code, and good > programmers have written bad code. > > Many examples can be found here in c.o.v where an outstanding *nix > script - C programmer struggles with DCL, and even the best DCL > programmer with no *nix experience won't write good bash script > without making more than a few "stupid" mistakes. > > Anyone who's ever been tasked with modifying or maintaining code > written in an unfamiliar language will understand that. Experience is > the key. Writing "bad code" doesn't make a person a "bad programmer." > A "bad programmer" probably won't last in that job and will likely end > up in management:-) > > > Even modifying or maintaining code written in a {\em familiar} language can be very difficult if you were not the author. It doesn't {\em have to be} difficult but poor choice of variable names and an absence of comments can make a program very difficult to understand. I could still understand and maintain code I wrote thirty years ago! I commented it liberally! Someone, I forget who, once wrote that "A computer program is not only a set of instructions for a computer but also a document which must be understood by human beings!" ------------------------------ Date: Thu, 20 Sep 2007 11:23:00 -0700 From: AEF Subject: Re: despair Message-ID: <1190312580.941296.293910@19g2000hsx.googlegroups.com> On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: > In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF writes: > > > On Sep 20, 12:24 pm, "Tom Linden" wrote: > >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF 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 ------------------------------ Date: 20 Sep 2007 14:18:45 -0500 From: briggs@encompasserve.org Subject: Re: despair Message-ID: In article <1190312580.941296.293910@19g2000hsx.googlegroups.com>, AEF writes: > On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: >> In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF writes: >> >> > On Sep 20, 12:24 pm, "Tom Linden" wrote: >> >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF 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. ------------------------------ Date: Thu, 20 Sep 2007 13:48:32 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 12:18:45 -0700, 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 ------------------------------ Date: Thu, 20 Sep 2007 13:56:34 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 09:37:08 -0700, Michael Kraemer wrote: > In article , Ron Johnson > > writes: >> >> C's[0] null-terminated strings, lack of bounds checking in arrays >> and memxxx functions, and manual heap control are open invitations >> to all sorts of nasty bugs. >> >> Those open invitations mean that C isn't, IMNSHO, suitable for >> anything beyond squeezing kernels into PDP-11s. >> >> Burroughs got it right by making an ALGOL variant it's system >> programming language. (I *think* it has had try-catch since the 1960s.) >> >> [0] And by extension Unix, since just about everything in the Unix >> world is written in C or C++, or calls libraries written in C. >> > > Unless you have forgotten several smileys or irony tags, > I think that's nonsense, sorry. > > The things you can do wrong in C/C++ are incorrect in any > other language as well. It has been one of the first lessons > in my programming courses (Fortran) that you should not write > to locations you do not own. Back then the pitfalls were mostly array > indices, > with more modern languages these would be pointers. > > And the advantage of languages supporting e.g. bounds checking, > PL/I for example (sorry Tom), is not that large. For that, you need > descriptor > areas, and these can be overwritten or trashed as well. > Which is rather easy since arguments are passed by reference (IIRC) > and not by value, as in C. Moreover, in the old times when I still > coded PL/I, the recommendation was to enable bounds checking only > for testing, but to disable for production, for performance reasons. > Unfortunately the most nasty errors occur at production time, > not at testing time. Wrong pointers can't be checked easily anyway. Our PL/I the bounds checking is done in the prolog, when needed (*-extents for example) otherwise as inline code and that you would have a hard time trashing. The VMS PL/I compiler is a better product than the MVS PL/I compiler you were using, Michael, in the days of Prof. Hultsch at GSI. > > I have experienced less C seg faults than protection exceptions > in the old PL/I mainframe days. > > There's a lot of useful and correct C/C++ code out there, > and with a bit of discipline and usage of builtin facilities > like type checking, sizeof(), etc this isn't really a problem. > > BTW, zero-terminated strings ("ASCIZ",IIRC) > are a specialty of those ancient PDP-11 boxes, > would you call them trash therefore ? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 20 Sep 2007 13:59:08 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 10:43:07 -0700, AEF 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 ------------------------------ Date: Thu, 20 Sep 2007 21:44:55 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: despair Message-ID: In article , "Tom Linden" writes: > > >On Thu, 20 Sep 2007 10:43:07 -0700, AEF 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 ------------------------------ Date: Thu, 20 Sep 2007 15:59:34 -0700 From: "Tom Linden" Subject: Re: despair Message-ID: On Thu, 20 Sep 2007 14:44:55 -0700, VAXman- <@SendSpamHere.ORG> wrote: > In article , "Tom Linden" = > writes: >> >> >> On Thu, 20 Sep 2007 10:43:07 -0700, AEF 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 ------------------------------ Date: Thu, 20 Sep 2007 17:35:09 -0700 From: AEF Subject: Re: despair Message-ID: <1190334909.799962.210690@w3g2000hsg.googlegroups.com> On Sep 20, 3:18 pm, bri...@encompasserve.org wrote: > In article <1190312580.941296.293...@19g2000hsx.googlegroups.com>, AEF writes: > > > > > On Sep 20, 12:49 pm, bri...@encompasserve.org wrote: > >> In article <1190309266.107100.248...@50g2000hsm.googlegroups.com>, AEF writes: > > >> > On Sep 20, 12:24 pm, "Tom Linden" wrote: > >> >> On Thu, 20 Sep 2007 09:04:34 -0700, AEF 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 ------------------------------ Date: Fri, 21 Sep 2007 01:59:09 GMT From: John Santos Subject: Re: despair Message-ID: JF Mezei wrote: > Ron Johnson wrote: > >> C's[0] null-terminated strings, lack of bounds checking in arrays >> and memxxx functions, and manual heap control are open invitations >> to all sorts of nasty bugs. > > > > C's flaws are well known. And a good programmer will ensure he doesn't > fall into those traps. > > Yes, C is a two wheeled bike without the training wheels to ensure you > don't fall. Other languages still have the training wheels to ensure you Feh! C is like a 2 wheeled bike without fenders, chain guard or brakes. And no derailleur - you have to change gears by grabbing the moving chain and wrenching it sideways onto a different sprocket. And stop by rubbing your hand against the tire or rim, being careful of the spokes. > don't try to do something which the language designers didn't plan. > > But that means that you can do things in C that other languages don't > let you do. > Like rip your thumbs off. > And with the pedantic ANSI C, there is a lot more checking of your > program, function definitions etc than ever before. Welcome to the 1970's. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 20 Sep 2007 14:47:18 -0700 From: "Tom Linden" Subject: Xyplex Terminal Server with VMS Message-ID: Any of you using one of these? The unit I got doesn't have the card with the Nbase software. It can also be boot loaded from Alpha or VAX VMS. Any of you doing that? -- PL/I for OpenVMS www.kednos.com ------------------------------ End of INFO-VAX 2007.515 ************************