From: papresco AT calum DOT csclub DOT uwaterloo DOT ca (Paul Prescod) Subject: Re: Absolute file-path under bash (cygwin32) 19 Apr 1997 10:22:53 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <3358D36F.372A156D.cygnus.gnu-win32@calum.csclub.uwaterloo.ca> References: <199704170243 DOT TAA05434 AT tcp DOT com> <3356C745 DOT 2E4A AT netcom DOT com> <335876B2 DOT D805DF89 AT calum DOT csclub DOT uwaterloo DOT ca> <33589BF7 DOT 57B AT netcom DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.0b3 [en] (Win95; I) Original-To: Jim Balter Original-CC: scott AT statsci DOT com, Hawkeye , jeffdb AT netzone DOT com, gnu-win32 AT cygnus DOT com X-Priority: 3 (Normal) Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 AT cygnus DOT com" with one line of text: "help".