Re: Absolute file-path under bash (cygwin32)

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

Jim Balter wrote:
> 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.

All I hope to achieve is uniformity. If the cygwin apps work reliably
with DOS paths then I am done. I'll have to look into adding completion
to my bash, but no path translating is necessary. But as we have each
pointed out in this thread, just because an app depends on cygwin
doesn't mean it works reliably with DOS paths.
 
> 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?

$/ (or whatever) is simply an invitation to "play with this data as
appropriate", as "*" is. Since it is hardly any work to do two-way
translation (DOS path to unix paths or unix to DOS) I was thinking that
the translation would go either way. Sorry for not being explicit.
 
> 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?

I expect the programs to work reliably in other shells to the extent
that cygwin.dll does all of their work for them and unreliably in other
situations, where they parse paths themselves.

--

I'm going to skip this red herring, since I didn't say anything about
Windows programs understanding Unix paths interactively:
 
> > 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".

I'm going to skip this one because I didn't say that gnu-win32 should
influence the interactive use of Win32 programs on my system:

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

I'll skip this because I'm not interested in meta-arguments about the
past:
 
> 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.  

"Partial support": Sometimes you can use DOS paths on Win32 where you
would have used Unix paths on Unix and sometimes you cannot.

> > completion being an example.
> 
> Example of what?  

An example of the fact that the apps have not been specifically
"localized" for Win32. You agree, but seem to just like arguing about
it.

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

I didn't claim it was surprising, merely that it was fact. The apps
"partially" support DOS file names through cygwin.dll . Bash command
completion is an example. I don't know which apps will safely manipulate
DOS paths, and I certainly don't know which apps that will be compiled
in the future will safely manipulate DOS paths. Thus I proposed to serve
the apps the paths they expect according to a flag on the executable and
a flag (e.g. $/) on the command line. If DOS filename support in the
Unix apps is really never a problem then I've been needlessly paranoid
and I'll just move to using DOS paths consistently.
 
> 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.

cygwin.dll is part of the bash program. Thanks to cygwin.dll, bash can
understand DOS-style PATHs. Bash cannot do commandline completion. Thus
bash has partial support for DOS command lines. If DLLs do not count as
part of the programs that use them then Netscape has no support for HTML
and Word for Windows has no support for Win32 paths!
 
> > 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.

My conclusion was that the apps have not been explicitly modified for
Win32 and that they would generally have exactly the level of DOS path
support that they got for free from cygwin.dll . Which means that in
some contexts only Unix-style paths will work. Which means that I cannot
consistently depend on both DOS and Unix-style paths to work correctly.
Which brings me back to the idea that I would rather have the shell
remember which paths go with which apps. Which, like anything else, I
can implement myself but might be worth implementing in bash itself.
 
 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".