Mail Archives: cygwin/1997/04/19/18:37:09
Paul Prescod wrote:
> 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.
You continue to confuse things. cygwin programs allow DOS paths,
since cygwin.dll allows them. bash is of no help there. Your proposal
was for $/..., which was a change to allow *unix* paths for non-cygwin
programs. Please try to be coherent.
> On the command line I would prefix them,
What "them"? DOS paths or unix paths? There is no need to prefix
DOS paths when passing them to unix programs; just put them in
single quotes.
> 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?
There's a library routine to convert paths. You could write a
wrapper for it that you could invoke from bash with backquotes.
> > 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.
Bash does conform to the ISO POSIX spec, but I admit that's pushing
things a bit. But making syntax changes to command line languages
can have unforeseen repercussions and raise compatibility issues.
> > 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.
The first thing you need to get straight is what you are trying
to accomplish. If you want to use DOS paths all the time, you can
do that now to the degree that individual unix programs don't parse
path names, and to the degree they do, bash can't help you.
If you want to use unix paths all the time, well, you just can't
with interactive programs, as I already pointed out. You said
above that the logic doesn't follow, but in fact it does if you
stop being confused.
> > 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.
I don't know why you presume such things, when presuming things about
software is so often a mistake. Your comment about quadruple
backslashes indicates a tendency to confuse levels. The library,
the individual commands, and the shell are all different levels.
If you want bash to do command line completion of DOS paths, you
are starting to talk about another shell; the windows NT cmd.exe
can do command line completion. 4dos.exe can do command line
completion. bash, like the rest of the tools, provides unix semantics.
If you start adding DOS path completion, that opens the door to about
ten thousand other changes. You need to have your goals clear up front.
> 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?
Since it isn't documented to do so, it's not a bug, eh?
But I can't tell you what features Cygnus plans to add in the 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.
There seems to be quite a bit of false belief based upon "presumption"
operating here where knowledge is required instead.
--
<J Q B>
-
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".
- Raw text -