Absolute file-path under bash (cygwin32)
Sat Apr 19 09:37:00 GMT 1997
Paul Prescod wrote:
> Jim Balter wrote:
> > This discussion has become rather confused. The topic *was*
> > having *non*-cygwin programs understand *unix* path names, by,
> > for instance hacking bash (I have faith that cygnus won't do this).
> Threads shift.
The thread has not shifted. Hawkeye apparently misinterpreted it, and
thought that the discussion was about making programs understand both
DOS-style names and unix-style names, and suggested changing the library
to handle both styles. But the library *already* handles both styles.
That doesn't help programs like vim understand unix paths, which was the
topic and apparently, from the fact that you are still discussing
bash, still is, since the only programs that need assistance from
bash are non-gnu-win32 programs, like vim.
> The question now is how to have a unified interface for
> passing paths to programs.
As it always was. But you must distinguish between gnu-win32 programs
that understand both forms of path, and non-gnu-win32 programs like
vim that only understand DOS paths. The topic is and always was how to
pass unix paths to non-unix programs; Hawkeye temporarily shifted it
to how to pass DOS paths to unix programs, which isn't really an issue.
> Do you feel that this is not a problem worth
> solving or that there is a better solution than changing bash?
Well, first, I believe it is a problem worth staying clear on,
and not confusing with some other problem, and a problem worth
knowing the facts about before wandering too far down a path.
I believe that adding command line syntax to bash is a hack
that doesn't fully address the problem and isn't really necessary.
There aren't a large number of non-gnu-win32 command line programs
that gnu-win32 users actually use, and they can be encapsulated
in bash aliases or functions. And for programs like vim (or emacs)
most of the paths that you give it are interactively, after you have
started the program, and they all have to be DOS-style paths.
One way or the other, you will have to deal with both. If you really
really hate them and you really really have command line programs
that aren't linked with gnu-win32 that you use often, you can write bash
functions as front ends, and then you wouldn't even need the $/
I find the "let's change bash" argument rather odd coming from someone
who has argued for the purity of HTML, but perhaps getting rolled over
by a steamroller changes one's outlook. :-)
And of course, if you want to do something to your copy of bash that you
think will make your life easier, you can; bash is free software.
> > b17 already groks DOS paths (device:, backslash); b18 will handle UNC
> > paths (paths starting with double backslash).
> Wouldn't that be a quadruple backslash (at least in bash)?
\\\\ is one way to enter a double backslash into bash. There are
others. Consult the documentation if you aren't familiar with them.
There are also other ways to enter paths than via bash.
It would be bizarre to refer to the syntax of a win32 path according
to one way to enter them via bash. People would look at you funny
if you told them that the elements of DOS paths are separated by
double backslashes ("Wouldn't that be a single backslash (at least
not in bash)?")
In any case, under both win32 and cygwin, slash and backslash are
theoretically interchangeable at the system level. Whether individual
programs understand both is another matter. Many or most DOS command
line programs don't handle paths with slashes because slash is the
switch character, and some cygwin programs don't understand paths with
backslashes because they look for a leading slash or separate directory
and filename components.
> Does that
> mean that Cygwin apps will understand paths with backslashes in them or
> that there is now a way to specify UNC paths so that Unix programs can
> understand them -- but using a different syntax than you would use for
> Windows programs.
cygwin apps do and will understand things like 'c:\' and 'c:/'.
They do not understand things like '\\share\foo' and '//share/foo', due
to various bugs that will be (hopefully) fixed in b18. The former are
DOS paths. The latter are UNC paths.
But again, this is at the library level. Some individual programs,
for instance, process paths in such as way as to treat multiple slashes
as single slashes, as they are allowed to do under POSIX. No library or
bash change can alter that.
<J Q B>
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".
More information about the Cygwin