Mail Archives: djgpp/1998/09/15/21:53:33
At 10:38 AM 9/14/1998 +0300, you wrote:
>On Sun, 13 Sep 1998, Peter J. Farley III wrote:
>> What I meant to say was, execute the same make command under COMMAND.COM as
>> under bash; i.e.,
>>
>> make -f mktest
>
>No, you were clear about that, and that's exactly what I understood.
>What I did NOT understand is how could /bin/rm work from the makefile
>used in the above command invoked either from Bash or from
>COMMAND.COM. If "/bin/rm" works, so should "/BIN/rm", since Windows
>file I/O is case-insensitive.
>
>The problem is, as I see now, that you used "rm" as opposed to
>"/BIN/rm", but were talking about "/bin/rm" as opposed to "/BIN/rm",
>and I deleted your initial message with the makefile and so couldn't
>see the actual command lines.
Absolutely right. Apologies for my confusion.
>Now everything is clear: this ain't supposed to work at all, since
>SYSROOT is a Bash-only feature, and even Bash itself only uses it for
>its internal commands (i.e., it does NOT expand the file names back to
>their original full form when passing them to external programs).
Thanks for the info. I'll remember that.
>> But I thought make used the SHELL (or MAKESHELL) variable to invoke
>> (non-trivial) commands, doesn't it? "Non-trivial" being things other than
>> directory commands and such, right?
>
>No, it's the other way around. Make *avoids* calling the shell at all
>costs, since that is expensive (you invoke two programs--the shell and
>the one specified on the command line--instead of one, for each
>command line in the makefile). So it only calls the shell when the
>command line includes some shell features, like redirection, quoted
>arguments, wildcards, etc. In your case, none of these is present, so
>the shell is not called, and Make invokes "/BIN/rm" directly (via
>`spawnvpe').
Understood. And doesn't invoke the SYSROOT magic on the command, either,
so causing the failure.
>> (Hm-m-m... Let me test that statement... No! It does *not* find it!
>> "bash /bin/rm -f test.dat" gives "No such file or directory (ENOENT)", just
>> what make reports.)
>
>But if you invoke Bash interactively, and *then* type "/BIN/rm", it
>*will* work. This seems like some inconsistency in how Bash itself
>handles SYSROOT.
Not surprising, considering the complexity of bash. I've been meaning to
write Daisuke to inquire how his port of bash 2.x was going. He pointed me
to an alpha version on his website earlier this year, but I haven't heard
anything from him since.
>> I use SYSROOT and place all DJGPP under a level-one directory because I do
>> not want the various DJGPP directories at level one of the hierarchy --
>> there are and are likely to be many other things at level one of a drive.
>> It is also most convenient for backup to have all (or nearly all) DJGPP
>> files in one directory instead of having to specify all the DJGPP top-level
>> directory names to a backup process.
>
>IMHO, you will be much better off if you use SYSROOT *only* when
>running programs that need it, like your backup. I don't recommend to
>use it for anything else, since it is dangerous in routine
>operations. If anything, it should be never set to a directory below
>the root (i.e. SYSROOT=c:).
>
>SYSROOT was originally invented to make Unix shell scripts work,
>because they would choke on DOS-style drive letters when they take
>apart PATH and similar colon-separated directory lists. However, with
>the introduction of the PATH_SEPARATOR feature, SYSROOT is in my
>opinion obsolete, since it only works when your PATH references a
>single drive.
Not strictly true, since bash *does* change "other drives" into "//x/..."
in the PATH variable, thus eliminating the colon problem. I have used
"PATH_SEPARATOR=:" with consistant good results when running various
configure-type scripts (until this problem, of course). I will try doing
without SYSROOT, setting "PATH_SEPARATOR=;", and see what happens.
>In any case, if you use these variables in your routine
>work, you should watch closely to not let their consequences crawl
>into your Makefiles, because that won't work. That is why, for
>example, when running configure scripts, I usually set
>INSTALL=${DJDIR}/bin/ginstall in the environment so that the Makefile
>won't end up with //c/djgpp/bin/install or some such.
But wouldn't this work? Doesn't bash translate "//c/djgpp/bin/install"
into something like "c:/djgpp/bin/install" before calling spawnvpe?
(Assuming no SYSROOT defined, of course.)
>One trick to force Bash to expand those pathnames is something like
>this:
>
> var=`echo.exe "$var"`
>
>This assigns the full DOS-style pathname to $var (assuming that
>PATH_EXPAND is set to Y). Note that you MUST use "echo.exe", since
>Bash only expands pathnames when it invokes external commands, and
>there's the internal `echo' of Bash itself which won't expand.
Good trick, maybe one which should be included in the various AC_PROG_...
macros in the DJGPP port of autoconf? Of course, that suggestion brings us
back to our discussion earlier this year (or was it last year?) about
whether bash (and many other utilities) should be prerequisite for building
DJGPP software, and I don't want to get back into that. Maybe the "right"
way is to set up and/or enhance package-specific autoconf aclocal.m4 files,
so as not to break more than is fixed. I'll play with this idea and see
whether it works.
I will try to keep all this in mind in continuing to work on Midnight
Commander (on which Bob Bowman has made much more progress than I have).
Thanks for all the info and advice.
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
pjfarley AT banet DOT net)
- Raw text -