Re: Absolute file-path under bash (cygwin32)

[Paul Prescod <papresco at calum dot csclub dot uwaterloo dot ca>]

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@cygnus.com" with one line of text: "help".