ls

[Amedee Van Gasse (ub)]

On Wed, January 27, 2010 01:46, nepal wrote:
> On Tuesday 26 Jan 2010 23:39:10 Amedee Van Gasse (ub) wrote:
>> On Tue, January 26, 2010 23:12, nepal wrote:
>> > On Tuesday 26 Jan 2010 21:03:53 Linda wrote:
>> >> Is there a way to make ls silent if there is no match? I'm not
>> >>  finding  it in the options, but am hoping I'm just reading over
>> >> it in the man page. Thanks
>> >>           Linda
>> >
>> > Hi Linda
>> >
>> > File a bug report!
>> >
>> > The correct response to *ls* for a non-existent target should be
>> > an empty list.
>>
>> Not true. For example:
>>
>> amedee at intrepid:~/download$ ls q*
>> ls: kan geen toegang krijgen tot q*: Bestand of map bestaat niet
>
> I have no idea what that is supposed to mean? If you say it is not
> true can you *explain* please.

This is the first time ever that I had to dig up the source of a program
to settle an argument. I hope it will be the last time too...

In the coreutils source, in ls.c, you will find the following piece of
code starting on line 2818:


      if (err != 0)
        {
          /* Failure to stat a command line argument leads to
             an exit status of 2.  For other files, stat failure
             provokes an exit status of 1.  */
          file_failure (command_line_arg,
                        _("cannot access %s"), absolute_name);
          if (command_line_arg)
            return 0;

          f->name = xstrdup (name);
          cwd_n_used++;

          return 0;
        }


You see, nepal? If ls can't stat an argument (like a filename with or
without wildcard), it will throw an error. Statting a file means getting
its properties from the filesystem.

> Let me put it another way then, the command "ls" is supposed to return
> a list, that is the meaning of the shortened version of the word list
> (ls).

I am not an idiot, nepal. I have taken AND passed an LPI exam. (Linux
Professionals Institute)

> The command is not supposed to make clever comments like I
> cannot find what you asked for. That is not what was asked for.

That's not what the source code says, and the source code is always right.
Of course there is a remote possibility that you have hacked your version
of ls and that you have stripped it from all error reporting, but I find
that very unlikely.

> Talk to
> it like it is an idiot. "ls" is a command. I command you (computer) to
> list whatever you find at this location.

Your comment is not very helpful for Linda (topicstarter).

> Then fancy options like having a message display upon returned errors
> can be provided to give the user the appropriate level of choice for
> information returned. But the default should be the basic primary
> function which is to return a list of a given location.

Again, not helpful for Linda.

>> As an alternative, you could use find with xargs and feed that to
>>  ls. If find doesn't find anything, nothing will be sent to ls and
>>  no output will be produced.
>> As an additional advantage, this solves problems when you have
>>  directories with thousands or millions of files.
>>
> So I maintain that no output should be produced other than the actual
> listing of a location, unless specifically requested by the user.
> Actually providing information not asked for is a coder's problem (I
> used to be but happily gave it up), it has now got to the point where
> it has its own name, software bloat.

Again, wrong. Basic error reporting is part of normal program operation,
and Linux even makes it easy by giving us not one but two outputs: out
(first output) and err (second output). By default, output 1 and 2 are
both printed to the console, but they can be redirected.

That's why Werner's suggestion will probably be the simplest solution for
Linda: just redirect the error output (second output) to something else
than the console, for example to /dev/null aka the bit bucket:

ls [non-existing filename] 2>/dev/null


For me this thread is closed. Linda has an answer that will work (Linda,
please say so if you still have problems). I'm not interested in further
discussion because that does not help Linda.

-- 
Amedee