Subject: Re: Absolute file-path under bash (cygwin32)
From: [email-masked] (Jim Balter)

20 Apr 1997 01:30:11 -0700
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Mozilla 4.0b2 (WinNT; I)
MIME-Version: 1.0
Original-To: Paul Prescod <[email-masked]>
Original-CC: [email-masked]
X-Priority: 3 (Normal)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Original-Sender: [email-masked]

Paul Prescod wrote:
> 
> 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.

Well no, it wasn't.  But in any case,

$ cat '/foo'
$ cat 'c:\foo'

They look well-differentiated to me.  As long as you are so vague,
it is hard to know what you are proposing or what you hope to achieve.

> > 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,

converted *from* what *to* what?  Unless you specify these each and
every time, you are incomprehensible.  If what you mean is that I should
be able to type

$ cat '$/c:\foo'

and have bash convert that into '/foo' so that the unix program
doesn't get confused, then
a) you have never suggested anything like that before
b) it doesn't look very appealing

The problem is that your proposal, $/, doesn't seem to have anything to
do with what you now seem to be talking about, being able to type
DOS paths on the command line but have unix programs receive unix
paths.  I'm just guessing that's what you mean, because you have never
said it explicitly.  If that is what you mean, what is your proposal
for doing it?

> 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.

Which, for unix programs, is unix paths.  So what is your proposal
for typing DOS paths at bash but having unix programs get unix paths?
And how do you expect the same programs when they are run from shells
other than bash?

> Bash
> predigests the path variable in this way.

NO IT DOES NOT.  Please stop making claims that aren't based upon
knowledge.  cygwin.dll converts PATH, not bash.  And it can do so cuz
it says "PATH", and everyone knows what that means; there's no
ambiguity.  But the same is not true of arbitrary path names.

> I have no problem writing that
> function but wanted to explore its greater usefulness with other users.

But you are talking about a change to bash, not a function.
And you specifically asked me what *I* thought of it, so I told you.

If you want to use unix commands with DOS path names, you could
write a program, as a shell script or in C, that converted all DOS-style
path names in its argument list to unix-style path names, and passed the
new arg list to the program given by first argument.  You could then
alias most of your unix commands to invocations of that program,
and you would then be able to run your unix commands using DOS paths
with no extra syntax and no changes to bash.  This would work with
nearly all unix programs, because they don't normally expect
backslashes in their arguments.  For those few that do, such as grep,
you could have a special case for the pattern argument.

If that's what you want to do.  But you started out wanting to pass
unix paths to DOS programs, and that's a different kettle of fish
because / is the DOS flag character.  But you could use your $/
in that case.  A different front end program, a different alias list.
But such an alias list is simple to create.  That, in my opinion, is
the right way to do what you say you want to do, and doesn't require
anything beyond competent use of the tools that already exist.

> > 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.

Not all interactive Windows programs will ever understand unix paths
because not all authors of interactive programs give a hoot about unix.
And, in fact, it works the other way around too.  I would love it
if emacs would understand unix path semantics.  I pointed out to
Geoff Voelker, the author of ntemacs, that ntemacs treats paths
relative to the drive of the current file, which can be very confusing
and messes up elisp functions that use paths like "/tmp" and expect
them to be absolute, and his response was simply "but it's Windows
semantics".

Keep in mind that gnu-win32 is an environment for running unix tools on
win32 systems.  It doesn't have any magic powers to make "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.

I guess I foolishly assumed that you knew something of what gnu-win32
and cygwin.dll are, so that when Geoff Noer announced that UNC paths
would be supported in b18, that you already had some idea as to what
"supported" meant.  It means "in cygwin.dll".

> The various apps
> have only partial support for DOS paths, with bash command line

No, the various apps have virtually NO support for DOS paths; all the
support comes by virtue of the cygwin.dll library.  Perhaps this is your
fundamental misunderstanding; the gnu-win32 apps are for the most
part original untouched UNIX code.  They have not been modified
for running under a Windows environment.  The major exception are
the compilation tools, and there the changes are to support Windows
binaries, not paths.

> completion being an example.

Example of what?  bash doesn't expand DOS path names, and it doesn't
shine you shoes either.  Hardly surprising for a unix shell.

> If there are no other apps that have
> half-support for DOS paths then translating them is probably

What do you mean by "half support"?  All the apps have the same
level of support, namely if they do something like
stat("c:\\", &statbuf) it recognizes that and sez it's a directory,
because that's implemented in cygwin.dll.  bash is no different.
You've just fantasized that, because bash doesn't do command line
completion of DOS paths, that it has "half support".  But bash doesn't
contain *any* support for DOS paths.  The support is in cygwin.dll.

> unneccessary. I had no luck when I tried DOS paths for bash command
> completion,

Well someone would have had to have written that code, wouldn't they?
It doesn't just happen by magic.  So to get from the fact that
bash didn't have completion for DOS paths added to it to *any
conclusion* is just not thinking clearly.

> I cannot find documentation for the various tools

It's forever beta free software.  If you want to know how it works,
read the code; that seems to be about as much as you are going to get
from Cygnus.  If you want documentation, you should be spending money
for a real (but no source) product like OpenNT, or UWIN, or MKS toolkit,
the latter giving you DOS paths to your heart's content.  

> and thus I
> presumed

Stop doing that; you don't seem to be very good at it and it isn't
good for you.

> that all paths must be mapped to Unix paths.

Um, they are entered as unix paths, if that is what you mean.
But the fact that bash doesn't do path completion has no bearing
on whether cygwin.dll understands DOS paths, and your *presumptions*
are ill-founded and ill-considered.

> 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.

Documentation?  Safety?  Look, this thing was thrown off the back of
a truck.  The library groks both DOS and unix paths.  Beyond that,
the tools are unix code.  The inferences are fairly straightforward.
 
> > 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.

It is different in principle because cygwin.dll is a
Windows-specific piece of code, whereas bash is a unix-specific piece of
code.
 
> > 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.

No, you're right, it isn't documented not to expand DOS pathnames.
Gee, why didn't I think of that.  But aside from the specious logic, no,
it was not supposed to expand DOS path names, cuz it's a unix shell, and
no one has yet turned it into a DOS shell.
 
> > 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.

But in the absense of same you proceed to presume, which is not a "safe"
course.  The specific case of false belief referred to above was
some notion that DOS shells pass "the 16 bit name" to win16 programs
and "the 32 bit name" to win32 programs.  But this is a fantasy that
came out of your own head and that you then took, upon the power of your
own presumption, as truth.

--
<J Q B>
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".