In "the old days" ls used to look at the environment variable
LS_OPTIONS.  I want to use a complex --time-style but I'd like it
to work for *all* ls invocations.  The usual advice to use

 alias ls="ls --time-style=whatever"

works only when bash gets to process the command.  The canonical
example would be !ls -l from a program like ftp.  This seems to exec
the ls program directly so aliases and similar shell tricks have no
effect.

Is there any way to get the old behaviour back?

-- 
Ben.

On 2008-06-05, Ben Bacarisse  wrote:

> In "the old days" ls used to look at the environment variable
> LS_OPTIONS.  I want to use a complex --time-style but I'd like it
> to work for *all* ls invocations.  The usual advice to use

Well, a simple option would be to replace the ls binary with a script
that forced your default options then passed $* to the command to pass
across the rest of the options to the moved original ls command.

Are you sure LS_OPTIONS is ignored?  I've never used it.  If it's
still there then thwack it into the system-wide /etc/profile file and
see if that helps (you'd need to log out then log in again).

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Ian Rawlings  writes:

> On 2008-06-05, Ben Bacarisse  wrote:
>
>> In "the old days" ls used to look at the environment variable
>> LS_OPTIONS.  I want to use a complex --time-style but I'd like it
>> to work for *all* ls invocations.  The usual advice to use
>
> Well, a simple option would be to replace the ls binary with a script
> that forced your default options then passed $* to the command to pass
> across the rest of the options to the moved original ls command.

When I first read it I was not keen on this, but I've just checked and
all the programs I can think of use $PATH, so I can so this without
resorting to changing /bin/ls.  I can have my custom ls in, say,
/usr/local/bin so, thanks, that is certainly one way to go.

One small point (for anyone else copying this): $* goes wrong on some
argument lists.  I /think/ the safe way is:

  /bin/ls --my-options "$@"

> Are you sure LS_OPTIONS is ignored?  I've never used it.  If it's
> still there then thwack it into the system-wide /etc/profile file and
> see if that helps (you'd need to log out then log in again).

Pretty sure.  strings /bin/ls shows that it is not in the binary
(LS_BLOCK_SIZE and LS_COLORS are) and I can't get it to do anything.
Shame, really...

-- 
Ben.

Ben Bacarisse wrote:
>
> One small point (for anyone else copying this): $* goes wrong on some
> argument lists.  I /think/ the safe way is:
> 
>   /bin/ls --my-options "$@"

    The argument lists in questions being ones with spaces in them.  To 
be safe on older Bourne-type shells on all system you should use 
${1+"$@"} to avoid getting a null parameter when you get passed none.


-- 
              Just because I've written it doesn't mean that
                   either you or I have to believe it.

Ben Bacarisse  wrote:
> When I first read it I was not keen on this, but I've just checked and
> all the programs I can think of use $PATH, so I can so this without
> resorting to changing /bin/ls.  I can have my custom ls in, say,
> /usr/local/bin so, thanks, that is certainly one way to go.

If this change is for a single user, consider putting the script in
$HOME/bin instead. Certainly on many of the systems I've used, there's a
line like this somewhere in the startup:

    test -d "$HOME/bin" && PATH="$HOME/bin:$PATH"

If there isn't on your system, consider adding it to .bash_profile
(or .profile).


> One small point (for anyone else copying this): $* goes wrong on some
> argument lists.  I /think/ the safe way is:
>  /bin/ls --my-options "$@"

Yes, that's right. There is a subtle difference between the variants of $*
"$*" and "$@":

    cat >args <<'x'
    echo 'Trying $*'; for A in $*; do echo "> $A"; done
    echo 'Trying "$*"'; for A in "$*"; do echo "> $A"; done
    echo 'Trying $@'; for A in $@; do echo "> $A"; done
    echo 'Trying "$@"'; for A in "$@"; do echo "> $A"; done
    x
    chmod a+x args
    ./args 'one two' three

Chris

"Chris Davies"  wrote in message 
news:b43mh5xo0j.ln2@news.roaima.co.uk...
> Ben Bacarisse  wrote:
>> When I first read it I was not keen on this, but I've just checked and
>> all the programs I can think of use $PATH, so I can so this without
>> resorting to changing /bin/ls.  I can have my custom ls in, say,
>> /usr/local/bin so, thanks, that is certainly one way to go.
>
> If this change is for a single user, consider putting the script in
> $HOME/bin instead. Certainly on many of the systems I've used, there's a
> line like this somewhere in the startup:
>
>    test -d "$HOME/bin" && PATH="$HOME/bin:$PATH"
>
> If there isn't on your system, consider adding it to .bash_profile
> (or .profile).
>

I believe that's considered a security risk, however like all risks you need 
to assess and choose if you want to live with it.

-- 
Geoff

Geoffrey Clements wrote:
> "Chris Davies"  wrote in message 
> news:b43mh5xo0j.ln2@news.roaima.co.uk...
...
>>If this change is for a single user, consider putting the script in
>>$HOME/bin instead. Certainly on many of the systems I've used, there's a
>>line like this somewhere in the startup:
>>
>>   test -d "$HOME/bin" && PATH="$HOME/bin:$PATH"
>>
>>If there isn't on your system, consider adding it to .bash_profile
>>(or .profile).
>>
> 
> 
> I believe that's considered a security risk, however like all risks you need 
> to assess and choose if you want to live with it.

Maybe you're thinking of the case where . is added to the PATH, rather 
than $HOME/bin?

Adding . would make the behaviour a bit more like windows, where the 
current directory is searched for a command first, before path 
directories[1]. This is a definite security risk, because if someone can 
get a wee script called ls in a directory somewhere, it would get run if 
someone (say, root) ever visited that directory and then tried to see 
what is in it by running ls. And that ls would behave like the "real" 
ls, apart from not showing itself in its output, except that it could 
also do anything else, with the priveliges of whoever invoked it.

Better to let everyone type ./ before a program name if they want to run 
the one in the current directory.


[1] This is, in turn, is to make the behaviour of DOS 2.x a bit more
     like DOS 1, and therefore CP/M 2.2, which did not have a PATH. So we
     live with the past, in the same way that dimensions on the space
     shuttle were said to have been determined by the size of a horse's
     arse in ancient Rome.

On Fri, 06 Jun 2008 13:15:22 +0100, Frank Peelo wrote:
> [1] This is, in turn, is to make the behaviour of DOS 2.x a bit more
>      like DOS 1, and therefore CP/M 2.2, which did not have a PATH. So we
>      live with the past, in the same way that dimensions on the space
>      shuttle were said to have been determined by the size of a horse's
>      arse in ancient Rome.

Not the entire shuttle, but the width of the boosters, so they could be
transported fromt he factory to the shuttle site.

-- 
Stephen Patterson :: steve@patter.mine.nu :: http://patter.mine.nu/
GPG: B416F0DE :: Jabber: patter@jabber.earth.li 
"Don't be silly, Minnie. Who'd be walking round these cliffs with a gas oven?"

Patter wrote:
> On Fri, 06 Jun 2008 13:15:22 +0100, Frank Peelo wrote:
> 
>>[1] This is, in turn, is to make the behaviour of DOS 2.x a bit more
>>     like DOS 1, and therefore CP/M 2.2, which did not have a PATH. So we
>>     live with the past, in the same way that dimensions on the space
>>     shuttle were said to have been determined by the size of a horse's
>>     arse in ancient Rome.
> 
> 
> Not the entire shuttle, but the width of the boosters, so they could be
> transported fromt he factory to the shuttle site.

I'd left it vague (not any /specific/ dimensions) because it might be an 
urban legend. But I'd never be one to let the truth get in the way of a 
good story.

> "Don't be silly, Minnie. Who'd be walking round these cliffs with a gas oven?"

Lady Docker?

On 2008-06-06, Patter  wrote:

> Not the entire shuttle, but the width of the boosters, so they could be
> transported fromt he factory to the shuttle site.

Isn't it amazing that in this day and age, we still eat food based on
the food eaten by cavemen!  Innit marvellous!

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

"Geoffrey Clements"  writes:

> "Chris Davies"  wrote in message 
> news:b43mh5xo0j.ln2@news.roaima.co.uk...
>> Ben Bacarisse  wrote:
>>> When I first read it I was not keen on this, but I've just checked and
>>> all the programs I can think of use $PATH, so I can so this without
>>> resorting to changing /bin/ls.  I can have my custom ls in, say,
>>> /usr/local/bin so, thanks, that is certainly one way to go.
>>
>> If this change is for a single user, consider putting the script in
>> $HOME/bin instead. Certainly on many of the systems I've used, there's a
>> line like this somewhere in the startup:
>>
>>    test -d "$HOME/bin" && PATH="$HOME/bin:$PATH"
>>
>> If there isn't on your system, consider adding it to .bash_profile
>> (or .profile).
>>
>
> I believe that's considered a security risk, however like all risks you need 
> to assess and choose if you want to live with it.

That is why I slightly prefer the /usr/local/bin solution.  My setup
adds $HOME/bin to PATH, but at the end, rather than at the front.
Even then it is still a minor risk.  I'd be in trouble if someone
manged to put a malicious program called cd.. in $HOME/bin!

-- 
Ben.

Ben Bacarisse  wrote:
> I'd be in trouble if someone manged to put a malicious program called
> cd.. in $HOME/bin!

Irony aside, if someone else put any command into your $HOME/bin,
you've got a bigger security risk that you appear to realise. (Think
about default permissions on directories that you own...)

Chris

Chris Davies  writes:

> Ben Bacarisse  wrote:
>> I'd be in trouble if someone manged to put a malicious program called
>> cd.. in $HOME/bin!
>
> Irony aside, if someone else put any command into your $HOME/bin,
> you've got a bigger security risk that you appear to realise. (Think
> about default permissions on directories that you own...)

Quite.  It was a daft comment.  I prefer to keep my bin directory at
the end of PATH simply because it forces me to pick a name that is not
already used.  It means I can't accidentally mask an installed
program.

As far as I can see, the only security issues that might arise are
rather contrived social engineering ones (like persuading an admin to
run "sudo ls" from your login).

-- 
Ben.

Ben Bacarisse  wrote:
> Quite.  It was a daft comment.  I prefer to keep my bin directory at
> the end of PATH simply because it forces me to pick a name that is not
> already used.  It means I can't accidentally mask an installed
> program.

Interesting; I put $HOME/bin:/usr/local/bin at the front of the PATH
for exactly that same reason (so that I /can/ override an existing
command) :-)

Chris

Chris Davies  writes:

> Ben Bacarisse  wrote:
>> Quite.  It was a daft comment.  I prefer to keep my bin directory at
>> the end of PATH simply because it forces me to pick a name that is not
>> already used.  It means I can't accidentally mask an installed
>> program.
>
> Interesting; I put $HOME/bin:/usr/local/bin at the front of the PATH
> for exactly that same reason (so that I /can/ override an existing
> command) :-)

And I agree that that is the more normal case.  I do it on this
machine because I have an alternative since I am the "admin".  When I
want to override (as I have done now with ls) I can do it in
/usr/local/bin.  This has the small advantage that it applies to the
other accounts -- I use accounts to separate "work" from "play".

-- 
Ben.

Ben Bacarisse wrote:
>> Interesting; I put $HOME/bin:/usr/local/bin at the front of the PATH
>> for exactly that same reason (so that I /can/ override an existing
>> command) :-)
> 
> And I agree that that is the more normal case.

But is likely to cause problems.  You get to think that your override is 
the norm, and then write scripts that fail for others.
Leave system commands alone - create your own with your own names.


-- 
              Just because I've written it doesn't mean that
                   either you or I have to believe it.

Big and Blue  writes:

>Ben Bacarisse wrote:
>>> Interesting; I put $HOME/bin:/usr/local/bin at the front of the PATH
>>> for exactly that same reason (so that I /can/ override an existing
>>> command) :-)
>> 
>> And I agree that that is the more normal case.

>But is likely to cause problems.  You get to think that your override is 
>the norm, and then write scripts that fail for others.
>Leave system commands alone - create your own with your own names.

So? You then get to feel that that program with your own name is the norm
and write scripts that fail for others. If you are going to be stupid,
nothing will help you.

In article <8p03k.337$sg6.243@edtnps91>,
Unruh   wrote:
>Big and Blue  writes:
>>[Overiding ls]
>>But is likely to cause problems.  You get to think that your override is 
>>the norm, and then write scripts that fail for others.
>>Leave system commands alone - create your own with your own names.
>
>So? You then get to feel that that program with your own name is the norm
>and write scripts that fail for others. If you are going to be stupid,
>nothing will help you. 

ls is quite commonly used in scripts already. You have the choice of
being very careful not to break any of them, or just using another name.

In this case, I'd be inclined to go for the being careful approach
since my fingers know the ls command very well. I would want the
friendly behaviour on the command line (ie. interactive use) and the
normal beheaviour in scripts (non-interactive use).

[There's a school of thought that says that having different results
behaviours for interactive and non-interactive invocations is wrong,
however, ls has always been an exception to this rule - it behaves
differently when attached to a terminal since it has different column
behaviour when attached to a terminal.]

You can use $- in bash to check whether or not the shell is interactive.

Peter

Peter Benie  writes:

> In article <8p03k.337$sg6.243@edtnps91>,
> Unruh   wrote:
>>Big and Blue  writes:
>>>[Overiding ls]
>>>But is likely to cause problems.  You get to think that your override is 
>>>the norm, and then write scripts that fail for others.
>>>Leave system commands alone - create your own with your own names.
>>
>>So? You then get to feel that that program with your own name is the norm
>>and write scripts that fail for others. If you are going to be stupid,
>>nothing will help you. 
>
> ls is quite commonly used in scripts already. You have the choice of
> being very careful not to break any of them, or just using another name.
>
> In this case, I'd be inclined to go for the being careful approach
> since my fingers know the ls command very well. I would want the
> friendly behaviour on the command line (ie. interactive use) and the
> normal beheaviour in scripts (non-interactive use).

Taking care is good.  For example many scripts set PATH or use /bin/ls
just to be sure.  Since ls's time format may be locale specific, a
script is well advised to specify such things if it is going to
process the results.

-- 
Ben.

On Mon, 09 Jun 2008 00:02:35 +0100, Big and Blue wrote:

> Ben Bacarisse wrote:
>>> Interesting; I put $HOME/bin:/usr/local/bin at the front of the PATH
>>> for exactly that same reason (so that I /can/ override an existing
>>> command) :-)
>> 
>> And I agree that that is the more normal case.
> 
> But is likely to cause problems.  You get to think that your override is 
> the norm, and then write scripts that fail for others.
> Leave system commands alone - create your own with your own names.
>
This is my normal approach, but then I always check that a program doesn't
exist for a name I intend to use before I write my code. 

I'm a multiple login user - each login selects a particular area of
interest, e.g. word processing etc, web authoring, program development,
so stuff I write myself always ends up in /usr/local* so its available in
all logins. In this environment putting '.' first in the search path makes
developing later versions of my programs much easier.


-- 
martin@   | Martin Gregorie
gregorie. | 
org       | Zappa fan & glider pilot

Martin Gregorie wrote:
> 
> I'm a multiple login user - each login selects a particular area of
> interest, e.g. word processing etc, web authoring, program development,
> so stuff I write myself always ends up in /usr/local* so its available in
> all logins.

But you can still use your own command names rather than override system 
ones.

>       In this environment putting '.' first in the search path makes
> developing later versions of my programs much easier.

    That's worse.  It gives you a non-constant set of commands, since 
your command list is dependent on your current directory.  And it;s a 
security risk - you cd to someone else's directory and end up running 
their scripts under your id without realizing it.

It also means that bash has to update it's hashed command list when you cd.


-- 
              Just because I've written it doesn't mean that
                   either you or I have to believe it.

Big and Blue  wrote:
> But is likely to cause problems.  You get to think that your override is 
> the norm, and then write scripts that fail for others.

#!/bin/sh
#
PATH=/usr/local/bin:$PATH
...

But if I were writing scripts for others I wouldn't rely on commands in
/usr/local/bin anyway. They're for local scripts and by definition are
likely not to be anywhere else.

Chris

On Mon, 09 Jun 2008 23:46:14 +0100, Big and Blue wrote:

> Martin Gregorie wrote:
>> 
>> I'm a multiple login user - each login selects a particular area of
>> interest, e.g. word processing etc, web authoring, program development,
>> so stuff I write myself always ends up in /usr/local* so its available in
>> all logins.
> 
> But you can still use your own command names rather than override system 
> ones.
> 
Of course. I go out of my way to avoid overloading system commands and
tend to use aliases rather than scripts if I need to change a system
command.

>>       In this environment putting '.' first in the search path makes
>> developing later versions of my programs much easier.
> 
> That's worse.  It gives you a non-constant set of commands, since 
> your command list is dependent on your current directory.
>
Potentially thats true, but it only has an effect if I'm in a development
directory: I don't use ~/bin and tend not to add '.' to the search path
outside development directories. Using /usr/local/* for my own commands
makes the whole setup somewhat consistent.


-- 
martin@   | Martin Gregorie
gregorie. | 
org       | Zappa fan & glider pilot

In article <pan.2008.06.10.23.11.04.239064@see_sig_for_address.invalid>,
	Martin Gregorie wrote:

> Of course. I go out of my way to avoid overloading system commands and
> tend to use aliases rather than scripts if I need to change a system
> command.

Or trying to write a program with the same name as a shell built-in.

(In my case I wrote a little program called "test", and wondered why it
didn't work. Yes, I had "." in my PATH. It was over 10 years ago...)

-- 
Paul Martin

On 5 Jun 2008, Ben Bacarisse said:
> Pretty sure.  strings /bin/ls shows that it is not in the binary

Silly question, but why do people do this? The source code is at most
one command away and would answer questions like this definitively.

stringsing binaries is a kludge for people condemned to use proprietary
software.

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 5 Jun 2008, Ben Bacarisse outgrape:
> In "the old days" ls used to look at the environment variable
> LS_OPTIONS.

It never did so, but I've been carrying this patch around for years (and
never submitting it upstream, perhaps because it's not very pretty:
against coreutils 6.10, works with earlier versions too with minor
changes):

Index: coreutils/doc/coreutils.texi
===================================================================
--- coreutils.orig/doc/coreutils.texi	2008-02-06 21:16:25.000000000 +0000
+++ coreutils/doc/coreutils.texi	2008-06-13 09:21:54.000000000 +0100
@@ -644,6 +644,16 @@
 specified, @samp{-} can appear as any operand that requires a file
 name.
 
+@vindex LS_OPTIONS
+@cindex default options environment variable
+The @var{LS_OPTIONS} environment variable specifies default options to be
+placed in front of any explicit options.  For example, if @code{LS_OPTIONS} is
+@samp{--color=auto --human-readable}, @command{ls} behaves as if the two
+options @samp{--color=auto} and @samp{--human-readable} had been specified
+before any explicit options.  Option specifications are separated by
+whitespace.  A backslash escapes the next character, so it can be used to
+specify an option containing whitespace or a backslash.
+
 @menu
 * Exit status::                 Indicating program success or failure.
 * Backup options::              -b -S, in some programs.
Index: coreutils/src/ls.c
===================================================================
--- coreutils.orig/src/ls.c	2008-02-06 21:16:25.000000000 +0000
+++ coreutils/src/ls.c	2008-06-13 09:25:23.000000000 +0100
@@ -202,7 +202,9 @@
 			  struct quoting_options const *options,
 			  size_t *width);
 static char *make_link_name (char const *name, char const *linkname);
-static int decode_switches (int argc, char **argv);
+static int decode_switches (int *pargc, char ***pargv);
+static int prepend_args (char const *options, char *buf, char **argv);
+static void prepend_default_options (char const *options, int *pargc, char ***pargv);
 static bool file_ignored (char const *name);
 static uintmax_t gobble_file (char const *name, enum filetype type,
 			      ino_t inode, bool command_line_arg,
@@ -1155,7 +1157,7 @@
   print_dir_name = true;
   pending_dirs = NULL;
 
-  i = decode_switches (argc, argv);
+  i = decode_switches (&argc, &argv);
 
   if (print_with_color)
     parse_ls_color ();
@@ -1368,11 +1370,64 @@
   exit (exit_status);
 }
 
+/* Find the white-space-separated options specified by OPTIONS, and
+   using BUF to store copies of these options, set ARGV[0], ARGV[1],
+   etc. to the option copies.  Return the number N of options found.
+   Do not set ARGV[N] to NULL.  If ARGV is NULL, do not store ARGV[0]
+   etc.  Backslash can be used to escape whitespace (and backslashes).  */
+static int
+prepend_args (char const *options, char *buf, char **argv)
+{
+  char const *o = options;
+  char *b = buf;
+  int n = 0;
+
+  for (;;)
+    {
+      while (isspace ((unsigned char) *o))
+	o++;
+      if (!*o)
+	return n;
+      if (argv)
+	argv[n] = b;
+      n++;
+
+      do
+	if ((*b++ = *o++) == '\\' && *o)
+	  b[-1] = *o++;
+      while (*o && ! isspace ((unsigned char) *o));
+
+      *b++ = '\0';
+    }
+}
+
+/* Prepend the whitespace-separated options in OPTIONS to the argument
+   vector of a main program with argument count *PARGC and argument
+   vector *PARGV.  */
+static void
+prepend_default_options (char const *options, int *pargc, char ***pargv)
+{
+  if (options)
+    {
+      char *buf = xmalloc (strlen (options) + 1);
+      int prepended = prepend_args (options, buf, (char **) NULL);
+      int argc = *pargc;
+      char * const *argv = *pargv;
+      char **pp = (char **) xmalloc ((prepended + argc + 1) * sizeof *pp);
+      *pargc = prepended + argc;
+      *pargv = pp;
+      *pp++ = *argv++;
+      pp += prepend_args (options, buf, pp);
+      while ((*pp++ = *argv++))
+	continue;
+    }
+}
+
 /* Set all the option flags according to the switches specified.
    Return the index of the first non-option argument.  */
 
 static int
-decode_switches (int argc, char **argv)
+decode_switches (int *pargc, char ***pargv)
 {
   char *time_style_option = NULL;
 
@@ -1504,10 +1559,12 @@
       }
   }
 
+  prepend_default_options (getenv ("LS_OPTIONS"), pargc, pargv);
+
   for (;;)
     {
       int oi = -1;
-      int c = getopt_long (argc, argv,
+      int c = getopt_long (*pargc, *pargv,
 			   "abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UXZ1",
 			   long_options, &oi);
       if (c == -1)


-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 2008-06-13, Nix  wrote:

> Silly question, but why do people do this?

Because it's quick.

> The source code is at most one command away

I'd say it's a tad more than one command..

> stringsing binaries is a kludge for people condemned to use
> proprietary software.

Or for people who have better things to be doing than digging through
the source code for "ls"!

You're right though, it was a silly question.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Nix  writes:

> On 5 Jun 2008, Ben Bacarisse said:
>> Pretty sure.  strings /bin/ls shows that it is not in the binary
>
> Silly question, but why do people do this? The source code is at most
> one command away and would answer questions like this definitively.

Why is it silly to ask why people do something?  It seems to me to be
a totally reasonable question.

I do it because it takes a fraction of a second.

-- 
Ben.

Nix  writes:

> On 5 Jun 2008, Ben Bacarisse said:
>> Pretty sure.  strings /bin/ls shows that it is not in the binary
<snip>
> stringsing binaries is a kludge for people condemned to use proprietary
> software.

Extra, Extra!

That is of course why I stared using it.  Even if the source had been
available, I think I would have used it since on those old systems man
was really quite slow.  I used to use strings xxx | grep '^[A-Z_]*$'
as a very quick and dirty "what was that environment variable, again?"
command.

Anyway, just did that to test and I was pleasantly surprised to see:

WVSQ
QUOTING_STYLE
LS_BLOCK_SIZE
COLUMNS
TABSIZE
TIME_STYLE
LS_COLORS
POSIX
BPOSIXLY_CORRECT
BLOCKSIZE
KMGTPEZY

Which suggests that ls might use TIME_STYLE, presumably to control the
time style.  This is exactly what I originally wanted and, as it turns
out, it works exactly as one would expect.  It is undocumented (I
really do read man pages before posting) so it may not work for others
nor in the future, but for now it means I don't need a local ls to get
the format I want.

I realise reading the source would also have revealed this, but there
is something to be said for simplicity.

-- 
Ben.

On 13 Jun 2008, Ian Rawlings said:

> On 2008-06-13, Nix  wrote:
>
>> Silly question, but why do people do this?
>
> Because it's quick.
>
>> The source code is at most one command away
>
> I'd say it's a tad more than one command..

`apt-get source' is one command.

But, OK, if you don't want to work out the package name,

apt-get source $(dpkg -s $(which ls) | cut -d: -f1)

but that's overdesign :)

>> stringsing binaries is a kludge for people condemned to use
>> proprietary software.
>
> Or for people who have better things to be doing than digging through
> the source code for "ls"!

grep is easy to type.

It just seems ridiculous to have the source (by definition easier to
understand than the binary) and yet still to be asking questions about
the behaviour of the system which are easy to determine by looking at
the source.

(But perhaps my perspective is distorted by having used C for over
2/3rds of my life. I can't remember what it's like not to know it very
well, and I do forget that other people don't know it.)

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 13 Jun 2008, Ben Bacarisse told this:
> That is of course why I stared using it.  Even if the source had been
> available, I think I would have used it since on those old systems man
> was really quite slow.  I used to use strings xxx | grep '^[A-Z_]*$'
> as a very quick and dirty "what was that environment variable, again?"
> command.

Well, that's reasonable and sensible, but... eeew. ;)

[...]
> KMGTPEZY

Weird. That's part of the getopt string for *shred*, not ls.

> Which suggests that ls might use TIME_STYLE, presumably to control the
> time style.

Er, this is clearly stated in the docs (section 10.1.6 in my copy,
_Formatting File Timestamps_). There's 117 lines in the info docs
devoted to nothing else.

>              This is exactly what I originally wanted and, as it turns
> out, it works exactly as one would expect.  It is undocumented (I

It is clearly documented in the documentation. The manpages don't
document every little wrinkle (this is possibly a bug, possibly not:
it's debatable whether wrinkles as small as the hundred variants of
TIME_STYLE should be documented in a format as unpleasantly linear as
man).

> I realise reading the source would also have revealed this, but there
> is something to be said for simplicity.

Reading the docs would help too.

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

In 
Nix  wrote:

> On 13 Jun 2008, Ian Rawlings said:
> 
> > On 2008-06-13, Nix  wrote:
> >
> >> Silly question, but why do people do this?
> >
> > Because it's quick.
> >
> >> The source code is at most one command away
> >
> > I'd say it's a tad more than one command..
> 
> `apt-get source' is one command.
> 
> But, OK, if you don't want to work out the package name,
> 
> apt-get source $(dpkg -s $(which ls) | cut -d: -f1)
> 
> but that's overdesign :)

And wrong :-P. You meant dpkg -S.

Personally I just tried:

LS_OPTIONS=-l ls

to confirm the variable is ignored!

-- 
TH * http://www.realh.co.uk

Nix  writes:

> On 13 Jun 2008, Ben Bacarisse told this:
>> That is of course why I stared using it.  Even if the source had been
>> available, I think I would have used it since on those old systems man
>> was really quite slow.  I used to use strings xxx | grep '^[A-Z_]*$'
>> as a very quick and dirty "what was that environment variable, again?"
>> command.
>
> Well, that's reasonable and sensible, but... eeew. ;)
>
> [...]
>> KMGTPEZY
>
> Weird. That's part of the getopt string for *shred*, not ls.

It is probably just coincidence.  Part of "eeww" is some of the output
is meaningless as text.

>> Which suggests that ls might use TIME_STYLE, presumably to control the
>> time style.
>
> Er, this is clearly stated in the docs (section 10.1.6 in my copy,
> _Formatting File Timestamps_). There's 117 lines in the info docs
> devoted to nothing else.

Hey!  There 100s of line of documentation, 117 about time formats
(that I did skim) but I missed the *one* line about the environment
variable.  Nobody suggested setting TIME_STYLE, so I suspect that
things documented in 'info' and not in 'man' pass quite a few people
by.  But thanks (seriously) for pointing it out that it is documented
-- I should have gone back to the info pages after seeing that the
option exists.

>>              This is exactly what I originally wanted and, as it turns
>> out, it works exactly as one would expect.  It is undocumented (I
>
> It is clearly documented in the documentation. The manpages don't
> document every little wrinkle (this is possibly a bug, possibly not:
> it's debatable whether wrinkles as small as the hundred variants of
> TIME_STYLE should be documented in a format as unpleasantly linear as
> man).

I have tried again and again to get on with info but I must confess to
disliking it every time I have to use it.  It is the linearity of man
pages that makes them just right for me.

>> I realise reading the source would also have revealed this, but there
>> is something to be said for simplicity.
>
> Reading the docs would help too.

I think I prefer code to info!

-- 
Ben.

Nix  writes:

> On 13 Jun 2008, Ian Rawlings said:
>
>> On 2008-06-13, Nix  wrote:
>>
>>> Silly question, but why do people do this?
>>
>> Because it's quick.
>>
>>> The source code is at most one command away
>>
>> I'd say it's a tad more than one command..
>
> `apt-get source' is one command.
>
> But, OK, if you don't want to work out the package name,
>
> apt-get source $(dpkg -s $(which ls) | cut -d: -f1)

You mean -S, I think.  The source tar file is one (or two) commands
away.  I think you need at least a tar command to get something
grep-able.

> but that's overdesign :)
>
>>> stringsing binaries is a kludge for people condemned to use
>>> proprietary software.
>>
>> Or for people who have better things to be doing than digging through
>> the source code for "ls"!
>
> grep is easy to type.
>
> It just seems ridiculous to have the source (by definition easier to
> understand than the binary) and yet still to be asking questions about
> the behaviour of the system which are easy to determine by looking at
> the source.

Someone asked me to check.  I could do

  strings /bin/ls | grep LS_OPTIONS

(unreliable, I know) or I could do

  apt-get source $(dpkg -S $(which ls) | cut -d: -f1)
  cd coreutils-6.10
  tar zxf coreutils-6.10.tar.gz
  grep -r LS_OPTIONS .

I am sure you know how long the above takes in comparison!  You make a
valid point (that the source is too often overlooked) but I don't
think my choice in this case was an odd one.

> (But perhaps my perspective is distorted by having used C for over
> 2/3rds of my life. I can't remember what it's like not to know it very
> well, and I do forget that other people don't know it.)

Ditto[1].  I read C with ease, but the kerfuffle of getting it and
tidying up is not trivial.  Now, if you'll excuse me, I just need to
'rm -r' a few things because I forgot to 'cd /tmp' before testing the
above!

-- 
Ben.

On 2008-06-13, Nix  wrote:

> On 13 Jun 2008, Ian Rawlings said:
>
>> On 2008-06-13, Nix  wrote:
>>
>>> Silly question, but why do people do this?
>>
>> Because it's quick.
>>
>>> The source code is at most one command away
>>
>> I'd say it's a tad more than one command..
>
> `apt-get source' is one command.

ianr@lounge ~ $ apt-get source
bash: apt-get: command not found

That's your one command used up!

Besides, once you've got the source, you have to find the bit for ls
and grep it, when you might as well do strings `which ls` | grep
LS_OPTIONS and that's good enough for this purpose.  After all if you
want to find out definitively then just grepping the source isn't good
enough, you have to go through it line by line.

> grep is easy to type.

About as definitive as grepping the output of strings though.

> (But perhaps my perspective is distorted by having used C for over
> 2/3rds of my life. I can't remember what it's like not to know it very
> well, and I do forget that other people don't know it.)

I find it ridiculous that people don't rebuild their own car engines,
after all it's not that hard to do..

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

In 
Ben Bacarisse  wrote:

> Nix  writes:
> 
> > Reading the docs would help too.
> 
> I think I prefer code to info!

I wonder if the reason nobody's written a decent info reader is because
they hope the format will die if nobody can read it.

-- 
TH * http://www.realh.co.uk

On 14 Jun 2008, Tony Houghton stated:

> In 
> Nix  wrote:
>
>> apt-get source $(dpkg -s $(which ls) | cut -d: -f1)
>> 
>> but that's overdesign :)
>
> And wrong :-P. You meant dpkg -S.

Typo. :)

> Personally I just tried:
>
> LS_OPTIONS=-l ls
>
> to confirm the variable is ignored!

Er. Yeah, that would work, too. (I think that's how I proved it before
adding the feature, way back in 1999 or whenever.)

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 14 Jun 2008, Ian Rawlings spake thusly:
> Besides, once you've got the source, you have to find the bit for ls
> and grep it,

src/ls.c ;) it's not hiding.

Plus you learn more.

>                  when you might as well do strings `which ls` | grep
> LS_OPTIONS and that's good enough for this purpose.  After all if you
> want to find out definitively then just grepping the source isn't good
> enough, you have to go through it line by line.

Yeah, *if* you think the source was written by obfuscatory maniacs. But
the GNU people aren't the sorts to put together LS_OPTIONS from ten
encrypted pieces :) they'll just type in the damn string. Most free
software projects are like that: the only ones I'll shy from grepping
are Mozilla and the enormous hairball which is OpenOffice.

>> (But perhaps my perspective is distorted by having used C for over
>> 2/3rds of my life. I can't remember what it's like not to know it very
>> well, and I do forget that other people don't know it.)
>
> I find it ridiculous that people don't rebuild their own car engines,
> after all it's not that hard to do..

Quite so! :)

*plans to rebuild the train taking him to work this morning, while it's
 in motion*

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 14 Jun 2008, Ben Bacarisse said:

> Nix  writes:
>> On 13 Jun 2008, Ben Bacarisse told this:
>>> KMGTPEZY
>>
>> Weird. That's part of the getopt string for *shred*, not ls.
>
> It is probably just coincidence.  Part of "eeww" is some of the output
> is meaningless as text.

Yeah, well, the thing is that's not a random meaningless string that the
assembler happened to spit out: it's an actual string constant which
appears in the source code... of a different program!

Strange, but probably completely boring.

>> Er, this is clearly stated in the docs (section 10.1.6 in my copy,
>> _Formatting File Timestamps_). There's 117 lines in the info docs
>> devoted to nothing else.
>
> Hey!  There 100s of line of documentation, 117 about time formats
> (that I did skim) but I missed the *one* line about the environment
> variable.

Ah, right. I wondered how you knew what to set it to! :)

>> It is clearly documented in the documentation. The manpages don't
>> document every little wrinkle (this is possibly a bug, possibly not:
>> it's debatable whether wrinkles as small as the hundred variants of
>> TIME_STYLE should be documented in a format as unpleasantly linear as
>> man).
>
> I have tried again and again to get on with info but I must confess to
> disliking it every time I have to use it.  It is the linearity of man
> pages that makes them just right for me.

Info is a *disgusting* viewer. pinfo is rather better. You can turn the
texinfo into HTML, as well, but few distros do this for you and for some
unaccountable reason the texinfo isn't installed along with the sources,
which makes it annoying to generate different formats.

>>> I realise reading the source would also have revealed this, but there
>>> is something to be said for simplicity.
>>
>> Reading the docs would help too.
>
> I think I prefer code to info!

You haven't seen info's code. ;}

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

In 
Nix  wrote:

> Info is a *disgusting* viewer. pinfo is rather better. You can turn
> the texinfo into HTML, as well, but few distros do this for you and
> for some unaccountable reason the texinfo isn't installed along with
> the sources, which makes it annoying to generate different formats.

There's also info2www, but you need to have a CGI-capable web server
running.

tkinfo is bearable, but you have to fiddle about with X resource files
to make it use sensible window and font sizes (and the fonts look
horrible on a modern desktop used to antialiasing), and if you try to
run a second copy it reverts to the awful default settings.

yelp could be nice, but it's excruciatingly slow, and incapable of
running long enough before crashing to do any serious browsing.

Emacs can be used as an info browser, and I presume it supports nice Xft
fonts these days. Unfortunately it's another program which tends to have
horrible default settings, and an overwhelming array of them to tweak.

-- 
TH * http://www.realh.co.uk

On Sat, 14 Jun 2008 01:54:38 +0100, Ben Bacarisse wrote:

> 
> I have tried again and again to get on with info but I must confess to
> disliking it every time I have to use it.  It is the linearity of man
> pages that makes them just right for me.
>
In this case the problem is the bloody awful documentation rather than the
use of info: neither the man page nor the info entry have a section
listing the environment variables configure ls.


-- 
martin@   | Martin Gregorie
gregorie. | 
org       | Zappa fan & glider pilot

On 14 Jun 2008, Tony Houghton uttered the following:

> In 
> Ben Bacarisse  wrote:
>
>> Nix  writes:
>> 
>> > Reading the docs would help too.
>> 
>> I think I prefer code to info!
>
> I wonder if the reason nobody's written a decent info reader is because
> they hope the format will die if nobody can read it.

Even RMS hates info, but there's no reason why the texinfo source (which
can produce much prettier output: it's designed to emit printed books,
after all) can't be used to spit out something far nicer to read.

It's just that this `something' doesn't yet exist, unless you think HTML
or PDF are the bee's knees.

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 2008-06-14, Nix  wrote:

> Info is a *disgusting* viewer. pinfo is rather better. You can turn the
> texinfo into HTML, as well, but few distros do this for you and for some
> unaccountable reason the texinfo isn't installed along with the sources,
> which makes it annoying to generate different formats.

One thing I hate about gentoo is that you either have to specify you
don't want documentation, or you specify you do and get a surprise
when some noddy little app tries to bring in the whole of LaTeX..

And even if you do specify you want docs then half the time it's just
the GPL info file and a README that refers you to the manual that's
included in the source tarball but not installed by the package :-/

It's still easier than building the system myself of course, just
having a moan..

> You haven't seen info's code. ;}

Bloody info!  Don't get me started!

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

On 2008-06-14, Nix  wrote:

> On 14 Jun 2008, Ian Rawlings spake thusly:
>> Besides, once you've got the source, you have to find the bit for ls
>> and grep it,
>
> src/ls.c ;) it's not hiding.

Yes but where is it stored?  Big disc you know!  Lots of directories!

By this time, someone with sense has already found the answer by much
simpler means..

> Plus you learn more.

Yeah, I'm desperate to find out about the inner workings of ls!

> Yeah, *if* you think the source was written by obfuscatory maniacs.

May well be, also you end up getting hot under the collar at the way
someone's written the code ;-)

>> I find it ridiculous that people don't rebuild their own car engines,
>> after all it's not that hard to do..
>
> Quite so! :)
>
> *plans to rebuild the train taking him to work this morning, while it's
>  in motion*

Well, people who don't replace their own cars are doomed to hunting
around for someone who won't rip them off and charge the earth for a
1-hour job, and they'll never know how the thing works!

So there!

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

On 2008-06-14, Ian Rawlings  wrote:

> Well, people who don't replace their own cars are doomed

Replace?  Repair I mean...

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

In 
Nix  wrote:

> On 14 Jun 2008, Tony Houghton uttered the following:
> 
> > I wonder if the reason nobody's written a decent info reader is
> > because they hope the format will die if nobody can read it.
> 
> Even RMS hates info, but there's no reason why the texinfo source
> (which can produce much prettier output: it's designed to emit
> printed books, after all) can't be used to spit out something far
> nicer to read.

I think even the info format could be OK with a decent reader. It has
sort of hyperlinks, so it has an advantage over man, and searches can
span a hierarchy of pages, so it even has an advantage over HTML.

I suspect it's preformatted for 80 columns with a fixed width font but a
decent reader might be able to reformat text to look nice at any
arbitrary column width and font within reason.

-- 
TH * http://www.realh.co.uk

On 14 Jun 2008, Ian Rawlings said:

> On 2008-06-14, Nix  wrote:
>
>> On 14 Jun 2008, Ian Rawlings spake thusly:
>>> Besides, once you've got the source, you have to find the bit for ls
>>> and grep it,
>>
>> src/ls.c ;) it's not hiding.
>
> Yes but where is it stored?  Big disc you know!  Lots of directories!

What? /usr/src, or perhaps you need to type in one or two commands to
get the source to that package.

The coreutils source tree is not a horrifying monster, and shying away
from looking at source rather than guessing about the behaviour of
binaries because your *disk* is big is, well, silly, IMNSHO.

>> Plus you learn more.
>
> Yeah, I'm desperate to find out about the inner workings of ls!

I've learnt several useful tricks from ls alone. :)

>> Yeah, *if* you think the source was written by obfuscatory maniacs.
>
> May well be, also you end up getting hot under the collar at the way
> someone's written the code ;-)

If you ignore the horrifying GNU libc makefiles, the source to GNU
programs was generally not written by obfuscatory maniacs and is quite
nice to read :)

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 14 Jun 2008, Martin Gregorie told this:
> In this case the problem is the bloody awful documentation rather than the
> use of info: neither the man page nor the info entry have a section
> listing the environment variables configure ls.

There really should be an environment variables index in the info file...

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 14 Jun 2008, Tony Houghton outgrape:
> yelp could be nice, but it's excruciatingly slow, and incapable of
> running long enough before crashing to do any serious browsing.

So I'm not the only person who's experienced this? It doesn't matter
what Mozilla backend I build it against, all it seems to be willing
to do is crash (sometimes at once, sometimes I actually get a single
page rendered and then it crashes).

Since I hardly ever use GNOME I don't care much.

> Emacs can be used as an info browser, and I presume it supports nice Xft
> fonts these days. Unfortunately it's another program which tends to have
> horrible default settings, and an overwhelming array of them to tweak.

Everyone who actually uses it has tweaked them into unrecognizability:
alas everyone tweaks them differently...

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 14 Jun 2008, Tony Houghton spake thusly:

> I think even the info format could be OK with a decent reader. It has
> sort of hyperlinks, so it has an advantage over man, and searches can
> span a hierarchy of pages, so it even has an advantage over HTML.

That's why I use it, yes :) but texinfo has loads of nifty extra
formatting which is discarded in the conversion to texinfo, and so
should be used as the source for any other conversions.

> I suspect it's preformatted for 80 columns with a fixed width font but a
> decent reader might be able to reformat text to look nice at any
> arbitrary column width and font within reason.

Yes, it's preformatted.

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 2008-06-15, Nix  wrote:

> What? /usr/src, or perhaps you need to type in one or two commands to
> get the source to that package.

.. or just use a far quicker method of finding out what you want and
prod the source only when you have to...  After all I'll bet most of
the time you read the documentation for a package first rather than
just dive into the source code and ignore the docs.

If you're used to reading the source then fine, but posting messages
telling people they should read the source or be doomed forevermore is
just nerding in the extreme.

> The coreutils source tree is not a horrifying monster, and shying away
> from looking at source rather than guessing about the behaviour of
> binaries because your *disk* is big is, well, silly, IMNSHO.

Meanwhile, someone sensible has figured out of LS_OPTIONS is still
used...

> I've learnt several useful tricks from ls alone. :)

Personally, I use it to list files!

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Nix  writes:

>> May well be, also you end up getting hot under the collar at the way
>> someone's written the code ;-)
>
> If you ignore the horrifying GNU libc makefiles, the source to GNU
> programs was generally not written by obfuscatory maniacs and is quite
> nice to read :)

I guess you're excluding GNU libc from the list, then :)


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

I demand that Tony Houghton may or may not have written...

[snip]
> tkinfo is bearable, but you have to fiddle about with X resource files to
> make it use sensible window and font sizes (and the fonts look horrible on
> a modern desktop used to antialiasing), and if you try to run a second copy
> it reverts to the awful default settings.

It's nicely anti-aliased here; perhaps you should install & use Tcl/Tk 8.5.

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants.      BUFFER AGAINST GLOBAL WARMING.

Each problem solved introduces a new unsolved problem.

In <4FB548C560%news@youmustbejoking.demon.cu.invalid>
Darren Salt <news@youmustbejoking.demon.cu.invalid> wrote:

> I demand that Tony Houghton may or may not have written...
> 
> [snip]
> > tkinfo is bearable, but you have to fiddle about with X resource
> > files to make it use sensible window and font sizes (and the fonts
> > look horrible on a modern desktop used to antialiasing), and if you
> > try to run a second copy it reverts to the awful default settings.
> 
> It's nicely anti-aliased here; perhaps you should install & use
> Tcl/Tk 8.5.

Thanks for the tip. I've got it working here now.

-- 
TH * http://www.realh.co.uk

On 15 Jun 2008, Ian Rawlings told this:

> On 2008-06-15, Nix  wrote:
>
>> What? /usr/src, or perhaps you need to type in one or two commands to
>> get the source to that package.
>
> .. or just use a far quicker method of finding out what you want and
> prod the source only when you have to...  After all I'll bet most of
> the time you read the documentation for a package first rather than
> just dive into the source code and ignore the docs.

I tend to grep the documentation, grep the source, and only *then*
*read* the docs. After all, grep is really fast, and if it *gives* you
answers they're generally right. :)

> If you're used to reading the source then fine, but posting messages
> telling people they should read the source or be doomed forevermore is
> just nerding in the extreme.

I didn't mention dooming them. It just seems strange to go to the
extreme of posting questions on USENET asking trivial questions about
the behaviour of a binary whose source is available. Surely it takes
longer to get an answer that way than to do a quick grep :)

>> I've learnt several useful tricks from ls alone. :)
>
> Personally, I use it to list files!

Hah, primitive. Didn't you know about the hidden game of rogue?

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

On 15 Jun 2008, Roger Leigh outgrape:

> Nix  writes:
>
>>> May well be, also you end up getting hot under the collar at the way
>>> someone's written the code ;-)
>>
>> If you ignore the horrifying GNU libc makefiles, the source to GNU
>> programs was generally not written by obfuscatory maniacs and is quite
>> nice to read :)
>
> I guess you're excluding GNU libc from the list, then :)

glibc is... special. I suppose GCC and Emacs are special too, for similar
reasons: they're huge systems which make heavy enough use of program-
internal infrastructure and macros that they might as well be written in
a private dialect of C :)

-- 
`If you are having a "ua luea luea le ua le" kind of day, I can only
 assume that you are doing no work due [to] incapacitating nausea caused 
 by numerous lazy demons.' --- Frossie

"Nix"  wrote in message 
news:87k5gqfgj8.fsf@hades.wkstn.nix...

[snip]

>> If you're used to reading the source then fine, but posting messages
>> telling people they should read the source or be doomed forevermore is
>> just nerding in the extreme.
>
> I didn't mention dooming them. It just seems strange to go to the
> extreme of posting questions on USENET asking trivial questions about
> the behaviour of a binary whose source is available. Surely it takes
> longer to get an answer that way than to do a quick grep :)
>

I think it may be of case of which path you tread the most. For someone used 
to typing a question in a newsreader that's going to be easier than 
refreshing one's memory on using grep and, oh yes, those darn regexes. 
However the grep/source route does get a definitive answer and quickly *if* 
you know what you're doing.

As a newsgroup ucol is one where you do get good quality answers but 
ironically this can encourage the former approach.

-- 
Geoff

On 2008-06-15, Nix  wrote:

> I tend to grep the documentation, grep the source, and only *then*
> *read* the docs. After all, grep is really fast, and if it *gives* you
> answers they're generally right. :)

I bring up the man page, then if I know what I'm looking for, start
using the search facililty, if that doesn't work, I run the command
with --help as a parameter, then if that doesn't work sometimes I'll
go and get something that's not so fecking obscure ;-)

> I didn't mention dooming them.

Doomed to always use proprietary code IIRC, quite how not reading
source dooms people to always using proprietary code I'm not sure
though..

> It just seems strange to go to the
> extreme of posting questions on USENET asking trivial questions about
> the behaviour of a binary whose source is available. Surely it takes
> longer to get an answer that way than to do a quick grep :)

Depends on how many hormonal nerds are around ready to do battle with
the scourge of the non-source-readers and their evil minions!

> Hah, primitive. Didn't you know about the hidden game of rogue?

No but given the amount of times I type "lsd" instead of "ls" I do get
worried about subliminal messages embedded in the output.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/