[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#169019: (startx fails to start x from console). FIX



On Friday 15 November 2002 08:42 am, John Lenton wrote:
> On Thu, Nov 14, 2002 at 11:40:46PM -0800, David Lawyer wrote:
> > I have found the cause of this problem and its solution.  The problem is
> > in the file /etc/Xsession (global Xsession file -- used by display
> > managers and xinit (startx)) supplied by the xfree86-common package.  So
> > please forward it to the maintainer of that package.
> >
> > In the above file there is function:
> > run_parts ()
> > which reads file names incorrectly if I'm at my console.  If I'm at a
> > dumb terminal, it works fine and typing startx will start x OK.  The
> > line in run_parts () that reads the files in directory $1 incorrectly is:
> >   for F in $(ls $1); do
> > Well, I've set up directory colors on my Linux box so that files are
> > color-coded by type of file.  I do this in my /etc/profile file:
> >
> > if [ $TERM = linux ]; then 		# set LS_COLOR environment variable
> >     eval `dircolors`;
> >     ls () { command ls --color $* ; }
>
> that should really be ls --color=auto, so that ls does what you expect
> when piping the result, for example. Nobody wants to grep escape codes.
Why not explicitly say --color=no?

> as to Xsession, it would be a good idea to either use unalias, or call
> ls by full name (i.e. /bin/ls). That's what the pesky
>
>    LS=/bin/ls
>
> is for at the top of a load of scripts...
There are env vars that can override default behavior if you are not careful, 
aren't there?

Warren Turkal
-- 
Treasurer, GOLUM, Inc.
http://www.golum.org





Reply to: