From: papresco AT calum DOT csclub DOT uwaterloo DOT ca (Paul Prescod) Subject: Re: Absolute file-path under bash (cygwin32) 19 Apr 1997 22:37:31 -0700 Sender: mail AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <3359986B.9C595223.cygnus.gnu-win32@calum.csclub.uwaterloo.ca> References: <199704170243 DOT TAA05434 AT tcp DOT com> <3356C745 DOT 2E4A AT netcom DOT com> <335876B2 DOT D805DF89 AT calum DOT csclub DOT uwaterloo DOT ca> <33589BF7 DOT 57B AT netcom DOT com> <3358D36F DOT 372A156D AT calum DOT csclub DOT uwaterloo DOT ca> <33596919 DOT 39FE AT netcom DOT com> X-Mailer: Mozilla 4.0b3 [en] (Win95; I) MIME-Version: 1.0 Original-To: gnu-win32 AT cygnus DOT com X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Original-Sender: owner-gnu-win32 AT cygnus DOT com Jim Balter wrote: > > You continue to confuse things. cygwin programs allow DOS paths, > since cygwin.dll allows them. bash is of no help there. Your proposal > was for $/..., which was a change to allow *unix* paths for non-cygwin > programs. Please try to be coherent. My proposal was to be able to use either style path as long as they were well differentiated. > Bash does conform to the ISO POSIX spec, but I admit that's pushing > things a bit. Good. > But making syntax changes to command line languages > can have unforeseen repercussions and raise compatibility issues. I'm certainly open to discussions of those issues and would not advocate any change that caused more problems then it solved. By analogy, people who don't understand all of the implications their ideas often suggest them to the HTML development mailing list. Usually they are bad ideas and I shoot them down. Sometimes they are good ideas and I agree with them. Either way I am glad that they tried because it lets us judge user need and sometimes get good ideas out of the process. > The first thing you need to get straight is what you are trying > to accomplish. If you want to use DOS paths all the time, you can > do that now to the degree that individual unix programs don't parse > path names, and to the degree they do, bash can't help you. That's what I don't understand. If a unix program parses its input using strtok or something, then the cygwin DLL can't help -- they will get confused regardless. If the paths are converted, either through a function I write or as part of bash, before they see them, then the apps will only get the input that they are used to dealing with. Bash predigests the path variable in this way. I have no problem writing that function but wanted to explore its greater usefulness with other users. > If you want to use unix paths all the time, well, you just can't > with interactive programs, as I already pointed out. If I could use a single tool consistently then that would be a big step forward. It will be a while before I can expect all interactive programs to be consistent. > > Kind of. Bash doesn't do command line completion on these paths so I > > presumed Cygwin apps didn't understand them. > > I don't know why you presume such things, when presuming things about > software is so often a mistake. Your comment about quadruple > backslashes indicates a tendency to confuse levels. The library, > the individual commands, and the shell are all different levels. I'm quite aware of this. But since the thread is about bash and the command line tools, when you said that B18 would understand \\foo\bar I wanted to know exactly what you were talking about. The various apps have only partial support for DOS paths, with bash command line completion being an example. If there are no other apps that have half-support for DOS paths then translating them is probably unneccessary. I had no luck when I tried DOS paths for bash command completion, I cannot find documentation for the various tools and thus I presumed that all paths must be mapped to Unix paths. If there is documentation somewhere that tells me where it is "safe" to use DOS paths, then I will know which tools I should treat specially. > If you want bash to do command line completion of DOS paths, you > are starting to talk about another shell; the windows NT cmd.exe > can do command line completion. 4dos.exe can do command line > completion. bash, like the rest of the tools, provides unix semantics. > If you start adding DOS path completion, that opens the door to about > ten thousand other changes. You need to have your goals clear up front. I don't see the existance of other tools as relevant. Bash is much more powerful than cmd.exe and there are various benefits over 4dos.exe as well. I didn't and don't yet see DOS path completion as a big hairy deal, but I'm not a bash expert and have not looked at the source code. It certainly does not seem any different in principle than win32 console support or DOS file handling in the cygwin DLL. Nor does it seem more difficult than either of those. > Since it isn't documented to do so, it's not a bug, eh? I don't know. It isn't (AFAIK) documented to not do so either. That's why I asked. Maybe it was supposed to work. > There seems to be quite a bit of false belief based upon "presumption" > operating here where knowledge is required instead. Well, that's why I'm here! If there is some documentation on DOS-style path support in bash and the tools, other than warnings in the readme about things that are especially broken then I would love to read it and learn more. Paul Prescod - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".