Absolute file-path under bash (cygwin32)

Paul Prescod papresco@calum.csclub.uwaterloo.ca
Sat Apr 19 09:37:00 GMT 1997

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

I guess it depends on who you are. I mix them up quite a bit.

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

I don't see how that logic follows. Most DOS/Win programs need DOS-style
paths, and are interactive. Most Cygwin programs need unix paths, and
are commandline driven. It seems to me, then, that if the commandline is
changed to allow DOS paths, then a huge percentage of the time I can use
DOS paths. On the command line I would prefix them, and not elsewhere,
but that's an easy kind of "ui thing" because command line mode is very
different than "dialog box" or "editor line" mode. I would only have to
be careful in .rc files and so forth.

> 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 $/
> convention.

It isn't clear how I get bash to do the fixup for me. Is there a user
level function to do that or do I have to write one?
> 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. :-)

I don't see the analogy. Bash is software. Software changes. Big deal.
I've never seen anything from GNU that I would call "pure". It evolves
to fit its environment. I'm sure if Stallman had his way bash would be a
Scheme REPL loop. So arguments from purity don't strike me as relevent
in this context. If we were discussing the "ISO Bourne Shell Language
Specification" then purity would count.

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

I intend to. I like to make other people's lives easier too, though. If
it turns out that I am not really the only person that is annoyed by
having to switch back and forth, and if there is an easy, backwards
compatible change that will correct it, then I will argue for it.
> cygwin apps do and will understand things like 'c:\' and 'c:/'.

Kind of. Bash doesn't do command line completion on these paths so I
presumed Cygwin apps didn't understand them. This is a case of what you
mention next:

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

Is the fact that bash does not do completion on DOS-style paths a bug
that will be fixed in the near future?

> No library or
> bash change can alter that.

Bash cannot change the program's code, but it can feed them what they
are expecting in the large percentage of the time that I am using them
from it. I don't want to use Windows as an example of software
engineering but I believe it does this with win32 vs. win16/DOS
programs. DOS programs get fed the 16 bit name, Win32 ones get fed the
32 bit one.

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

More information about the Cygwin mailing list