Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 32105 - alias l. is inadequate
alias l. is inadequate
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-03-17 19:10 EST by Michal Jaegermann
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-24 18:09:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2001-03-17 19:10:59 EST
Alias 'l.' defined in /etc/profile.d/colorls.sh fails in this that
it does not work called like 'l. /dev' and it will not catch infamous
security breaches like '...' and similar.  I would propose instead
the following fragment of 'colors.sh':

if echo $SHELL |grep bash 2>&1 >/dev/null; then # aliases are bash only
  if ! egrep -qi "^COLOR.*none" $COLORS &>/dev/null; then
        alias ll='ls -l --color=tty'
#       alias l.='ls -d .[a-zA-Z]* --color=tty'
        alias ls='ls --color=tty'
        alias ll='ls -l'
#       alias l.='ls -d .[a-zA-Z]*'
  function l. { local d="$1" ; [ "$d" ] && d="${d%/}/" ;
   ( shopt -s nullglob ; ls -d "$d".[^.] "$d".??* ) ; }

or maybe even define 'l.' function unconditionally.  Otherwise
people which will get into a habit of using 'l.' may be mislead
to a presence of problems.

Comment 1 Bernhard Rosenkraenzer 2002-08-29 18:33:33 EDT
Using your code is problematic because it's highly bash specific.
I've changed the alias to ls -d .* instead. That adds . and .., but I guess
that's not as bad as missing ... and the likes.
Comment 2 Michal Jaegermann 2002-08-29 19:56:01 EDT
> Using your code is problematic because it's highly bash specific.

As original 'l.' was protected by "if echo $SHELL |grep bash ..."
then I did not see anything wrong with a bash specific code but if you
have something better then by all means.

Note You need to log in before you can comment on or make changes to this bug.