On Sat, 2010-05-22 at 14:57 -0500, Bruce Dubbs wrote:
> That doesn't make sense. Both dircolors and ls are from coreutils. If
> you use the same version of coreutils to generate /etc/dircolors, then
> ls should understand it.
>
> On a recent LFS system, /etc/dircolors does not have an hl prefi
Rodolfo Perez wrote:
> I don't know about the newer coreutils. But the commend:
> dircolors -p > /etc/dircolors
> on blfs Version svn-20100501 seems to have caused my problem.
That doesn't make sense. Both dircolors and ls are from coreutils. If
you use the same version of coreutils to generat
> On 21.05.2010 09:40, Rodolfo Perez wrote:
> >> root [ /etc ]# ls
> >> ls: unrecognized prefix: hl
> >> ls: unparsable value for LS_COLORS environment variable
Thank you blfs-people for your advises, altough i resolved my problem
differently.
I "googled" and found out, that "older" coreutils had
On Sat, 2010-05-22 at 10:35 +0200, Nicolas Richard wrote:
> Also on bash, the builtin "type" seems to do the job of 'alias' and
> 'which' at the same time. Is there any drawback to using that one ?
Certainly not for an interactive shell - since it's a bash builtin,
it'll tell you *exactly* what ba
Le 21/05/10 12:05, Lars Bamberger a écrit :
> Find out what command is actually executed when you type 'ls'. Do a
> 'which ls' or 'alias ls' if which is not installed.
I think 'which' will not tell you if there is an alias (maybe it depends
on version used), so 'alias' might be a better first choi
