Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis
This was originally sent to cygwin and module authors list, but since File::Spec is part of core perl, it was suggested I move it to the perl5-porters list, though it's not really 'just' a porting issue, since it also involves the issue of how File::Spec should be _defined_ to behave (syntactic analysis in absence of checking with a local fs, since there is no guarantee that some paths are constructed for the current system, exceptions being routines like 'pwd'. Anyway...here it is (again) -- sorry for the duplication to the cygwin list, but cygwin folks are just special, ya know? :-) -l A bit late to the party, I know, but wanted to chime in on the Cygwin File::Spec discussion. I'm 'cc'ing the cygwin list as a "heads up" for any interested parties. A more satisfactory mapping is to base "Cygwin" on Win32, not Unix. Cygwin, as an "OS interface" _partially_ supports posix mapping -- it supports posix naming to the same extent the underlying Win32 OS supports it -- not to the level Unix supports it. For example, 1) "\:" are illegal in Cygwin pathnames as they are under Win32. Posix doesn't have this difference. 2) By default, case doesn't matter under Cygwin in the cases where it doesn't matter under Win32. It's not _ignored_ -- case is preserved on filename creation but not lookup. Ex: law/proj/fspec> touch aBcDe law/proj/fspec/tmp> ls aBcDe (expected) law/proj/fspec/tmp> mv ABCDE AbCdE (this works!) law/proj/fspec/tmp> ls AbCdE (case is changed) law/proj/fspec/tmp> touch aBcDe (try to recreate original filename) law/proj/fspec/tmp> ls AbCdE (win32 behavior, not posix behavior) 3) using unix and win32 syntaxes to parse valid cygwin filenames "i:/fee/fie/foe/fum" and "i:fee/fie/foe/fum" yield (under 5.8): unix:v,d,f=, i:/fee/fie/foe/, fum unix: 'i:', 'fee', 'fie', 'foe', '' Win32:v,d,f=i:, /fee/fie/foe/, fum Win32:'', 'fee', 'fie', 'foe', '' and unix:v,d,f=, i:fee/fie/foe/, fum unix: 'i:fee', 'fie', 'foe', '' Win32:v,d,f=i:, fee/fie/foe/, fum Win32:'fee', 'fie', 'foe', '' Under cygwin, you cannot create a filename "i:fee" -- it creates a filename 'fee' (somewhere**) on the "i:" filesystem (volume). => For some reason that eludes me, the current File::Spec implementation => returns a 'null' directory as the last directory component while no such => component existed in the original pathname. I would tend to think this is a => bug. Elucidating comments? Agreement? Disagreement? Cygwin, and possibly, the Win32 module, are inconsistent in handling the differences between i:/foobar/ and i:. On one hand i: is considered a 'volume' but on the other hand i:/ seems to evaluate to the same, incorrect, value. In "Win32", each 'fs' of form ":', x of class <[:alpha:]>, there is a process-specific "current directory". This can be seen by: >From cmd.exe, cygwin utils "ls", "pwd", "printenv" and "grep" are in my path. 1) Fresh cmd shell, what's on filesystem "Z"? C:\Documents and Settings\law>dir /b /a z:## /a=show hidden, /b=skip header desktop.ini Content.IE5 ## expected output, /a=show hidden files C:\Documents and Settings\law>ls z: Content.IE5 desktop.ini## again, expected output... 2) Where are we? C:\Documents and Settings\law>cd C:\Documents and Settings\law ## expected -- shows same as the ## default prompt: C:\Documents and Settings\law>echo %prompt% $P$G## $p=cur drive and path, $g=">" C:\Documents and Settings\law>pwd ## on cygwin? /cygdrive/c/Documents and Settings/law ## hmmm...cygwin translated c: to ## /cygdrive/c; seems like under ## cygwin, /cygdrive/c is a win32 volume. 3. What does File::Spec say about that? ishtar:law/proj/fspec> fspec "c:Documents and Settings/law/" Win32:v,d,f=c:, Documents and Settings/law/, Win32:'Documents and Settings', 'law', '' ## expected, C: is a fs (volume) cygwin: v,d,f=, c:Documents and Settings/law/, cygwin: 'c:Documents and Settings', 'law', '' ## oops, seems File::Spec::Cygwin ## doesn't act the same way the Cygwin ## layer does...>>not good<<, bug? 4. How about "/cygwin/c/Documents and Settings/law" ? cygwin: v,d,f=, /cygwin/c/Documents and Settings/law/, cygwin: '', 'cygwin', 'c', 'Documents and Settings', 'la
RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis
> -Original Message- > From: Hack Kampbjorn [mailto:[EMAIL PROTECTED]] > > Cygwin, and possibly, the Win32 module, are inconsistent in > handling > > the differences between i:/foobar/ and i:. On one hand i: is > > considered a 'volume' but on the other hand i:/ seems to > evaluate to > > the same, incorrect, value. In "Win32", each 'fs' of form > ":', x of > > class <[:alpha:]>, there is a process-specific "current > directory". > > This can be seen by: > > > In the old DOS days yes, but in Win32 there is only one current > directory. The illusion of having a current directory per > drive and an > active drive is maintained in cmd.exe (or is it in the MS C > runtime?). Most programs seem to recognize this convention, for example, "notepad.exe", "win32-GVIM", Adobe Acrobat, vbs scripts. Do you know of any programs that don't behave this way? > As cygwin doesn't use it, i:foobar and i:/foobar is always the same. --- Always? Like when 'foobar' = '*'? law> echo z:* z:* law> echo z:/* z:/Content.IE5 z:/OLKAD7 z:/desktop.ini z:/foo z:/stardock_activedesktop.pdf z:/ which.txt IMO, this is "wrong" behavior: 1) C:\>dir /a /b z: foo.txt foobar.txt foobar.txt.000 stardock_activedesktop.pdf C:\>ls z: Content.IE5 OLKAD7 desktop.ini foo stardock_activedesktop.pdf 2) Take your pick -- if I launch bash from the above CMD.EXE -- bash will ignore win32's curdir for Z:, but if then launch a win32 app like Gvim, directly from bash and write a file "z:new", then when I exit gvim and do an "ls z:" the file isn't there. That's inconsistent with the underlying OS's concept of a current dir/drive. It's not just in 'cmd.exe' -- more likely in USER.DLL or some such, which pretty much makes it a part of the OS. law> /c/Program\ Files/Vim/vim61/gvim.exe (write out blank file to "z:new") law> ls z: Content.IE5/ OLKAD7/ desktop.ini foo/ stardock_activedesktop.pdf which.txt law> ls z:foo foo.txt foobar.txt.000 new.000 which.txt foobar.txt new stardock_activedesktop.pdf law> Do you think this is proper behavior? Do you think a win32 person being introduced to posix/gnu utils would find this beneficial? Do you think a linux person who uses some combination of cygwin and Win utils would find this beneficial? -l -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis
> Gurusamy Sarathy wrote: > > I agree with most of your points, and in particular with the one > > above. I consider File::Spec::Win32 currently broken because it > > hijacks all paths and turns them into the backslashed > variety, which > > is completely wrong from the portability POV. (By which I > mean that > > utilities written for UNIX that would otherwise work on windows are > > now broken because of this change.) > > The biggest problem with File::Spec::Win32 right now is the > fact that it > will allow _both_ types of slashes in a path. This has lead > to bugs like report [19213] > [http://rt.perl.org/rt2/Ticket/Display.html?id=19213] > > For portabillity, it would be fine if either a path would be > represented > as c:\perl\5.8.0\bin\perl.exe or c:/perl/5.8.0/bin/perl.exe > but never as c:\perl\5.8.0/bin/perl.exe --- If a user calls the 'normalize' function, it should convert it to "\" -- since that is the OS standard/default -- HOWEVER... the OS accepts *either* -- so having Win32 accept paths that contain either is valid. File Spec is supposed to provide a way to manipulate paths that are valid on a particular OS. It isn't a supposed to be a "please convert me to posix, unix, or some form that someone thinks Win should have used". In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'. You have to quote the "/" so it won't be interpreted as a switch character -- but the underlying OS seems to not really care which you use and neither should Win32. As for the bug -- it is a red-herring issue -- the user calls the OS normal form for generating a pathname, then Perl itself choose not to use the OS normal form for its internally generated paths. I don't think it is a bug to use either -- bug certainly specifying the same library twice by two separate names shouldn't cause a core dump in any event. -l --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Repost, different list...File::Spec, Cygwin, Syntactic vs. Semantic path analysis
> -Original Message- > From: Elfyn McBratney [mailto:[EMAIL PROTECTED]] > I tend to agree that as windows uses the back-slash as a > default path seperator so should `normalize' but also in the > interest of compatability with windows 95 (in dos mode) as it > doesn't support the forward-slash path seperator. I'm not sure I'd use Win95 as an example of what one should use for compatibilities sake -- why draw the line there? Why not Win 3.0 or ...was there a Win 1.0?...Maybe PC-DOS 1.0... Even I wouldn't choose to support anything prior to Win98SE. Too many problems... However... > > > In "cmd.exe", you can type 'dir \' or you can type 'dir "/"'. > >You have to quote the "/" so it won't be interpreted as a switch > >character -- but the underlying OS seems to not really care which you > >use and neither should Win32. > > A bit OT but dir does not support the forward slash pathsep > even when quoted: > > C:\WINNT>dir "/" > >Directory of \\ > > File Not Found --- You're right...I know I typed it in somewhere last night and it worked, but it was getting a bit late...might have mucked up and typed it into a cygwin shell...:-) Weird OT examples follow preceeded by "# "... # Oddly the following does work (WinXPSP1): # 1) # C:\PCTemp>dir "/temp/w2k" # ... #Directory of C:\temp\w2k # 12-27-02 12:50a . # 12-27-02 12:50a .. # 12-27-02 12:58a Temp # 0 File(s) 0 bytes # 3 Dir(s) 9,374,515,200 bytes free # # But not with "cd": # 2) # C:\PCTemp>cd "/temp/w2k" # The system cannot find the path specified. # # ...I'm getting a headache...let's look at the source!...um...drat...can't # do that (probably no wonder given this weird behavior). # # I have no problem with normalizing in win32 Perl changing everything to "/". # Seems best for syntax parses -- perhaps it's a bug in samba to allow this, # but just for masochism's sake I recreated my weird pathname via samba on # linux: # 3) # ishtar:/tmp/law> ls -R /tmp/law # /tmp/law: # dirfoo/ does this path work linda\'s tmp dir in weird path dir # # /tmp/law/dirfoo: # footxt.txt # --- # cmd.exe: # 4) # C:\>dir /s "//ishtar/tmp/law" ##only seems to work with /tmp also # ##exported #Volume in drive \\ishtar\tmp is tmp #Volume Serial Number is 0ADF-016E #Directory of \\ishtar\tmp\law # 01-06-03 08:24a . # 01-06-03 08:30a .. # 01-06-03 08:19a 0 LINDA~EN # 01-06-03 08:21a 0 does this path work # 01-06-03 08:24a dirfoo # 2 File(s) 0 bytes #Directory of \\ishtar\tmp\law\dirfoo # 01-06-03 08:24a . # 01-06-03 08:24a .. # 01-06-03 08:24a 0 footxt.txt # 1 File(s) 0 bytes # --- # ## w/o /tmp exported and only /tmp/law, explorer shows it but neither cmd # nor explorer can access the directory. Oddly, 'dir' doesn't show shares # for the path "//ishtar" even though it can list the contents of shares # have to use "net view \\ishtar" (or // or \\ under cygwin). # (though neither cmd nor cygwin can display contents of "tmp/law" unless # "tmp" is also sharednet view shows: # # 5) # C:\root\tmp>net view \\ishtar # Shared resources at \\ishtar # Share name Type Used as Comment # # # homeDisk Home Directories # share Disk (UNC)Ishtar Share # tmp/law Disk Per user tmp dir to demo psycho path # The command completed successfully. # # # Anyway...seems like "/" works on network paths except in weird cases. # Also filenames with in them created on linux get an 8.3 # translation, but if created from win32 seem to work fine -- registry magic, # I guess...(?) So it seems that 'syntactically', one can't always determine if a "/" is invalid in a straight win32 environment -- at least not when a network name is involved, but I'd agree it is pathological and should be ignored (and documented as ignored for pathological share names) So I'd suggest the following: I. Win32 syntactic normalization should always proceed to return "\". Cygwin is a Posix compatibility layer for Win32, though -- it isn't supposed to be a complete replacement/invalidation of the underlying Win32 layer -- unless one wants to declare that "e:foobar" only can reference a file and simulate "foobar\fee" as a valid file (through some mechanism). For cygwin to be a useful constructor of utils -- it should hand both Posix names *and* win32 names. Normalization can return "/" for any filename that doesn't have, say, a in it -- but ... no... I agree it should alwa
RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis
> > Cygwin's primary purpose is to provide a UNIX environment for > Windows. Although it can be used in other ways, the basic > purpose is not to provide a stepping stone to helping port > programs to native Windows. Things like Win32 path names and > accommodating pure-win32 processes are > *always* of secondary importance wrt getting the UNIX bits right. --- Would you please contact RedHat and have them change the stated purpose of the project? It's very confusing: At http://www.redhat.com/software/cygwin/, it says: "Cygwin is a set of powerful tools to assist developers in migrating applications from UNIX/Linux to the Windows platform." That's the first and primary purpose listed. Later on, it says " In addition, it provides for a standard UNIX/Linux development environment on Windows including APIs and command shells. The Cygwin.dll library, included with Cygwin, delivers the interesting subset of UNIX SVR4, BSD, and POSIX APIs to enable quick ports of UNIX/Linux applications to the Windows platform." A stated project *feature* (in the next paragraph) is: "Standard Windows command line tools can even be intermixed within the UNIX/Linux shell script environment to administer the Windows system. Over the years, UNIX/Linux system administrators have developed a large toolbox set of management scripts for their UNIX/Linux machines. Cygwin provides the ability to continue using these scripts on Windows machines." In order to be able to seamlessly integrate cygwin tools with Windows tools in the same shell script environment and apply linux scripts to windows machines -- seamlessly, the linux scripts need to understand Windows pathnames. Now maybe you'd like to change "Cygwin" to be something other than what it was intended. If you really want a linux only environment -- I have had pretty good success with SuSE over the years. I've even regularly used Vmware to run Windows on top of my linux machine -- for *years* to provide Win access to my linux files and vice-versa. You are trying to change the original design goal of Cygwin by "vehement assertion" -- much like Microsoft tries to change the realities of software ownership and first-sale doctrine by "vehement assertion and threats of "legal bullying" (that logically, would eventually fail under current law...but in our system, it's those who have the most money to pay their warriors (lawyers) full-time to harass you that win their point by forfeit -- not court decision). MS, historically, on every patent case that they kenw they didn't stand a chance on, when the person was stubborn enough try to 1) buy rights to use the patent, 2) buy the patent, 3) buy the company that owns the patent, 4) negotiate business deals with the company that specify MS gets the patent (or use thereof) if they fall through -- and make the deal look attractive enough that the company is distracted by the 'gold' (fake gold) that appears to be in the deal for them. Then MS withdraws support, the company dies and MS gets the patent -- again by forfeit. So far, no one has withstood all of MS's patent acquisition tactics. It's not that MS is *right*, they just have the loudest and longest lasting voices -- PR department that try to reframe people's idea of what is normal. If you get enough people to believe a lie for long enough, it can become accepted as truth. In this situation, your vehement assertion not withstanding, the origins of the Cygwin project are clearly stated and they are not what you are claiming them to be. > > >Might that not imply some minimal understanding of the Win32 > >environment so as to integrate as seamlessly as possible with such? > > Nope. It's supposed to isolate you from the windows > environment. In theory, you shouldn't have to know or worry > about the :\ nonsense. --- More vehement assertion of incorrect facts. > Understanding that the OS uses :\ specially, and that the > filenames are case preserving but case insensitive, is, of > course, necessary. --- No more necessary than it is for you to run Windows. You could write your own file system layer -- port ext2 to Windows. Write your own API to the file system. At the *very* least, you could use a UTF-8 type encoding scheme to encode a 'colon' as some other sequence of bits. Under NT, there is a local policy that specifies whether or not to enforce case ignorance on all file systems -- you can *choose* not to have case ignored on subsystems that provide upper and lower case. Perhaps FAT32 as well -- just might not be a backward portable FS to Win98---but NTFS...*very* likely. > Understanding that double slashes at the > beginning of a path are special is good sense for any > portable program. --- There you go again, making relative assertions about "good/bad" again. It's common practice to define a $(ROOT)/foobar underwhich to build or install a program. It is common to have ROOT=/ when
RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis
> From: Robert Collins [mailto:[EMAIL PROTECTED]] > > There you go again, making relative assertions about "good/bad" > > again. It's common practice to define a $(ROOT)/foobar > underwhich to > > build or install a program. It is common to have ROOT=/ > when you want > > to install it on a live machine. It is *expected* that > double slashes > > "//" will be treated as "/". Thinking "//" is special only > shows the > > corrupting influence Win32 has had on your thinking. If > you grew up > > on unix, you'd know that "//" = "/". > > Whoa. POSIX uses // as a imeplementation specific prefix for > network paths. The posix 'dirname' algorithm EXPLICITLY > leaves the use of // as implementation specific. Go check it > up you want proof. === Ok, did I mention POSIX? Posix != Unix. So what's your point? I've been on multiple unices [bogus latinization, but unix's doesn't roll of the tongue nearly so well]: sun, hp, sgi, linux, xenix, sco, others I don't remember. I don't recall "//" being anything other than "/" on any of them, though my memory is most accurate for linux/SGI and I'm fairly sure about sun. But any OS is subject to change over the years. So who knows what is true now. But just because it is Posix doesn't mean its true for Unix. > Growing up on unix does NOT mean // == /. If you assume that > *anywhere* you will limit your programs portability > (specifically, you are IMMEDIATELY non-posix). --- That may very well be correct -- can you name some large user-base unix's that I might encounter where "//" != "/"? I'm not saying they don't exist, I just would like to know which of the larger vendors have a unix that functions that way. If none of them do, then my statement of 'growing up on unix' would still have most people with an experience of "//" reducing to "/". But POSIXly speaking, I cannot and do not refute what you claim. > > Dogma is an anesthetization of "critical thinking". > > Just curious, if that is the case, why do you make vehement > assertions of your own? --- For the same reason I do yoga? Thinking of the founding fathers of the US, can one believe they did not engage in critical thinking or that they were not vehement in their assertions against unjust leadership? And the meaning of your statement? Could you be more clear? I don't understand. Thanks, Linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Repost, different list...File::Spec, cygwin, Syntactic vs. Semantic path analysis
Interesting...wonder why they wouldn't just create pseudo devices in /dev and do the normal unix mount thing? Seems odd to complicate the simple namespace model needlessly by adding a special syntax. Even still, just because one wants to have more traditional unix names doesn't preclude the possible design goal of backward compatibility with existing Win32 pathnames to aid in portable tool usage and design. Even a hard coded /smb/ or /smb:/ prefix on smb shares would be a better choice that "//". Why perpetuate the MS view of SMB being 'special' vs. using an eventual mounting syntax that would allow it to coexist with /nfs/ type files? If the mount system evolved enough in cygwin, then I could see mount allowing specification of 'nfs' in a mount command -- either as a link to an MS-nfs method (assuming they were supply one) or cygwin-based NFS methods like the universal NFS server... -linda > Cygwin predates RedHat. See http://cygwin.com/history.html (the > earliest date in the file is Dec 1995). RedHat bought Cygnus > Solutions > (which was a shop for commercial support for GNU software, especially > GCC ports to obscure and new platforms), which did the > original Cygwin work. > > Anyone at RedHat from the original Cygwin team (the last > warriors of the > (in)famous "Beta 20" :-)?) wanna answer this? > > There's an interesting line in the early changelogs: > > Release Beta 8 > [...] > Much nicer way of describing paths, eg //c/foo is c:\foo. > > Suggests that the early goal *was* to provide a POSIX-y view, and the > exposing of Windows paths was added as a convenience.. > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: mean & grumpy (cygwin path analysis)
> What so it's the list managers fault? The reason you don't > have to subscribe to this list, I'm guessing, is to make it > easier for new user's post here instead of *forcing* them to > sign-up first. If thats being "different" and violates > "normal expectations" then I obviously cannot argue with you > on this matter. If you send a mail to a mailing list, come to > realise that you used the wrong address, do you then go back > and send it again even though it's already got there? === Well, not no more...now that I know this list doesn't bounce. > I think that was referring to why you we're sending > duplicates to the list YA. A lot of things are mean in your > opinion aren't they? --- Yep. Just a mean mean world. Very very sad...:-(((! (:-)) In fact, I think it is soooooo mean -- that... well it just is! Pblblblblt. > > > Banning simple HTML formatting in email is like banning magazine > > layout in > favor of 8.5x11 Courier-typed 'articles'. > > When you (and others on the list) sends mails they eventually > get processed by Mhonarc, the archiving software, and the > body of the message is placed in tags so even if HTML > formatting was allowed it wouldn't get the desired effect. > You will also find that this is not the only list on the net > that doesn't allow mime-encoded mails. I know -- a lot of lists don't -- its just that it's seems a giant step backwards in terms of communication -- even handwriting is more expressive -- even a real typewriter could do underlining, and bold. How about RTF? Is that portable enough? Just feels like I'm stuck in the 70's. The TTY's have gotten fancier, but its still mostly ascii text in terminal windows...sorta sad (not mean though..thats different), though it could be mean if it was a conspiracy...) :-) -l -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: >/dev/stderr broken in /bin/sh?, makewhatis unhappy, & apropos confused, or just me?
> -Original Message-
> From: Igor Pechtchanski [mailto:[EMAIL PROTECTED]
> Sent: Sun, Mar 09, 2003 8:59p
> To: linda w (cyg)
> Cc: [EMAIL PROTECTED]
> Subject: Re: >/dev/stderr broken in /bin/sh?, makewhatis
> unhappy, & apropos confused, or just me?
>
>
> Linda,
>
> A couple of points to note:
> 1) In Cygwin, /bin/sh != bash. /bin/sh == ash, and it doesn't support
>bash'isms like /dev/stderr. Use >&2 and >&1 in /bin/sh.
-
"Bash"ism?
>From Oreillynet:
Some UNIX systems, and utilities such as gawk, support
special filenames like /dev/stdin, /dev/stdout, and
/dev/stderr. You can use these just as you'd use other
files.
I just happened to look and it is on my SuSE system as well -- I didn't
know bash had special handling for it till just now...learn something
new every day!
Oh, you'll like this one: "Learn Linux in 15 minutes a week!":
http://www.2000trainers.com/article.aspx?articleID=144&page=2
Says /dev/std{in|err|out} are standard on linux systems.
Maybe Cygwin should be renamed "CyNUX": "Cygwin is Not
Unix or Linux"? :-)
I guess the author of 'makewhatis' didn't know this either. Perhaps
it's on enough systems.
> 2) While it's acceptable to have a space in your home directory name or
> the value of $TMP/$TEMP, some scripts cannot handle it (because they're
> missing proper quoting). My guess is that 'makewhatis' is one such...
"Acceptable"? Gee...thanks. Considering Windows comes that
way ...
> Don't know about the apropos bit...
> Igor
---
So I take it that it doesn't give bogus output on your system...
it's probably some file munged on my system somewhere...I'm alwayws
messing something up ... always using things in ways they were
never "intended" to be used...
Thanks for the heads up on basha simple fix for
makewhatis for it's use of /dev/stdX might be to make the first line
#!/bin/bash instead of #!/bin/sh.
Linda
>
> On Sun, 9 Mar 2003, linda w (cyg) wrote:
>
> > I normally use bash and this works in bash:
> >
> > echo "hello stderr" >/dev/stderr
> > echo "hello stdout" >/dev/stdout
> >
> > But in /bin/sh:
> >
> > $ echo hello stderr >/dev/stderr
> > cannot create /dev/stderr: directory nonexistent
> > $ echo hello stdout >/dev/stdout
> > cannot create /dev/stdout: directory nonexistent
> > $
> >
> > ---
> > I'm guessing this isn't supposed to work this way?
> >
> > "makewhatis -v" doesn't like seem to like it:
> > law> makewhatis -v
> > /usr/sbin/makewhatis: cannot create /dev/stderr: directory
> nonexistent
> >
> > I invoked the -v when a simple "makewhatis" yielded
> > "cd: can't cd to /cygdrive/c/Documents"
> >
> > Apropos is a little confused about one of it's lines.
> > Does anyone else get garbage on this:
> >
> > apropos options|wc -l|grep "^SYN"
> >
> > "wc" gives this:
> > law> apropos options|grep "^SYN"|wc
> > 12332 13924
> >
> > That's one heck of a long line. Do I just have some junk somewhere?
> >
> > I could attach it, but I don't want to unnecessarily send all that
> > junk out if it's easily reproducible.
> >
> > linda
>
> --
> http://cs.nyu.edu/~pechtcha/
> |\ _,,,---,,_ [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED]
> |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
> '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
>
> Oh, boy, virtual memory! Now I'm gonna make myself a really
> *big* RAMdisk!
> -- /usr/games/fortune
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
