From: jqb AT netcom DOT com (Jim Balter) Subject: Re: Absolute file-path under bash (cygwin32) 19 Apr 1997 11:46:34 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <33589BF7.57B.cygnus.gnu-win32@netcom.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: Paul Prescod Original-CC: scott AT statsci DOT com, Hawkeye , jeffdb AT netzone DOT com, gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com 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. That said: 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 $/ convention. 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. -- - 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".