Branden Robinson <[EMAIL PROTECTED]> writes:
>
> I'm still waiting for an explicit recommendation.
Just to chime in with my two cents worth, I'd say do nothing.
Anyone fiddling with standard commands has got to confine that to
their interactive shell (meaning using .bashrc or whatever), anything
Branden Robinson <[EMAIL PROTECTED]> writes:
>
> I'm still waiting for an explicit recommendation.
Just to chime in with my two cents worth, I'd say do nothing.
Anyone fiddling with standard commands has got to confine that to
their interactive shell (meaning using .bashrc or whatever), anything
On Thu, Nov 14, 2002 at 02:21:07PM -0600, Warren Turkal wrote:
> On Friday 15 November 2002 01:40 am, David Lawyer wrote:
> > for F in $(command ls $1); do
> >
> > The "command ls" insures that ls is not a shell function but the real ls
> > command.
> The following may be another solution
> for F i
On Thu, Nov 14, 2002 at 02:21:07PM -0600, Warren Turkal wrote:
> On Friday 15 November 2002 01:40 am, David Lawyer wrote:
> > for F in $(command ls $1); do
> >
> > The "command ls" insures that ls is not a shell function but the real ls
> > command.
> The following may be another solution
> for F i
I'm still waiting for an explicit recommendation.
--
G. Branden Robinson| Software engineering: that part of
Debian GNU/Linux | computer science which is too
[EMAIL PROTECTED] | difficult for the computer
http://people.debian.org/~bran
I'm still waiting for an explicit recommendation.
--
G. Branden Robinson| Software engineering: that part of
Debian GNU/Linux | computer science which is too
[EMAIL PROTECTED] | difficult for the computer
http://people.debian.org/~bran
On Thu, Nov 14, 2002 at 10:40:46PM -0600, Warren Turkal wrote:
> Why not explicitly say --color=no?
Because that introduces a dependency on GNU ls, and may break things
on BSD or odd Debian ports (Debian Solaris, for example). And it has
no corresponding benefits to make up for the lack of porta
On Thu, Nov 14, 2002 at 10:40:46PM -0600, Warren Turkal wrote:
> Why not explicitly say --color=no?
Because that introduces a dependency on GNU ls, and may break things
on BSD or odd Debian ports (Debian Solaris, for example). And it has
no corresponding benefits to make up for the lack of porta
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)
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 i
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)
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 i
On Friday 15 November 2002 01:40 am, David Lawyer wrote:
> for F in $(command ls $1); do
>
> The "command ls" insures that ls is not a shell function but the real ls
> command.
The following may be another solution
for F in $(ls --color=no -1); do
Also, the following will allow spaces in filenames
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 funct
On Friday 15 November 2002 01:40 am, David Lawyer wrote:
> for F in $(command ls $1); do
>
> The "command ls" insures that ls is not a shell function but the real ls
> command.
The following may be another solution
for F in $(ls --color=no -1); do
Also, the following will allow spaces in filenames
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 funct
On Wed, Nov 13, 2002 at 05:18:32PM -0800, David Lawyer wrote:
> Package: xbase-clients
> Version: 4.2.1-3
>
> When I type startx at the console, it creates an X window with an x in
> the center but it only lasts for about 1 second. I then get back to the
> text interface with "waiting for X serve
On Wed, Nov 13, 2002 at 05:18:32PM -0800, David Lawyer wrote:
> Package: xbase-clients
> Version: 4.2.1-3
>
> When I type startx at the console, it creates an X window with an x in
> the center but it only lasts for about 1 second. I then get back to the
> text interface with "waiting for X serve
Package: xbase-clients
Version: 4.2.1-3
When I type startx at the console, it creates an X window with an x in
the center but it only lasts for about 1 second. I then get back to the
text interface with "waiting for X server to shut down". Now if I snoop
with: startx 2&> me
I find that me contai
Package: xbase-clients
Version: 4.2.1-3
When I type startx at the console, it creates an X window with an x in
the center but it only lasts for about 1 second. I then get back to the
text interface with "waiting for X server to shut down". Now if I snoop
with: startx 2&> me
I find that me contai
20 matches
Mail list logo
