Date:	Sat, 29 Apr 2000 18:10:37 -0400 (EDT)
Message-Id:	<200004292210.SAA28184@indy.delorie.com>
From:	Eli Zaretskii <eliz AT delorie DOT com>
To:	Richard Dawe <richdawe AT bigfoot DOT com>
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<390A12B4.437341D9@bigfoot.com> (message from Richard Dawe on
	Fri, 28 Apr 2000 23:37:40 +0100)
Subject:	Re: Some questions about porting fileutils 4.0
References:	<39081435 DOT E2EDBC04 AT bigfoot DOT com> <39089981 DOT 16E7FAF7 AT bigfoot DOT com> <200004282213 DOT SAA26938 AT indy DOT delorie DOT com> <390A12B4 DOT 437341D9 AT bigfoot DOT com>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Fri, 28 Apr 2000 23:37:40 +0100
> From: Richard Dawe <richdawe AT bigfoot DOT com>
>
> > For example, the code in dircolors.c which looks at the shell name
> > should probably be made workable with DOS-style sh.exe and such, what
> > with so many people who use Bash for interactive sessions.
> 
> The shell seems to default to Bourne syntax, when SHELL is not set to csh
> or tcsh (the path is stripped off). Actually, I will need to strip off the
> '.exe' extension (and '.com') from that check.

Yes, that stripping of the extension is what I had in mind ;-).

> /* Get terminal type */
>   term = getenv ("TERM");
> #ifdef __DJGPP__
>   /* DJGPP port can always colorize, but TERM is not usually defined
> there. */
>   term = "console";
> #endif  
>   if (term == NULL || *term == '\0')
>     term = "none";
> 
> I was thinking that we might not want to override the setting of TERM if
> input was redirected and TERM was set to e.g. vt100. If this is unlikely
> to happen or we don't support output to different terminal types, then I
> guess we don't lose anything by ignoring TERM.
> 
> Basically, I'm curious why the setting of TERM is just discarded in
> fileutils 3.16's dircolors.

First, redirection is not necessarily relevant to `dircolors', because
it runs under a different environment than `ls'.  For example, you
could run `dircolors' without redirection, then say "ls --colors >foo".

The reason `dircolors' ignores TERM is that the method used for
colorization doesn't depend on TERM.  The original code assumes that
TERM stays constant and is a basic aspect of the user's interactive
environment; otherwise it won't make sense to suggest the value of
LS_COLORS based on the value of TERM at the time `dircolors' is run.
This assumption is not true for DJGPP, since TERM is usually not set
and is ignored by the colorization code.

Put it another way, `dircolors' is a tool to produce an appropriate
value for LS_COLORS.  It didn't make sense to tell DJGPP users that
they must have TERM set to a specific value in order to see the
correct results from `dircolors'.

> I found that 'ls c:' does not work in bash (in 3.16 and 4.0 ports). Even
> 'ls c\:' fails. Is this expected behaviour? 'ls c:' works OK from
> command.com.

I cannot reproduce this problem on my machine; "ls c:" works for me
both from COMMAND.COM and from Bash.  What version of Bash are you
using?  Is `ls' an alias maybe?  Or perhaps you have something else in
your _bashrc that produces this behavior?

- Raw text -