bug-coreutils
[Top][All Lists]
Advanced

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

bug#21325: ls : feature request --width=zero


From: Erik Auerswald
Subject: bug#21325: ls : feature request --width=zero
Date: Sun, 23 Aug 2015 15:00:32 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Sun, Aug 23, 2015 at 04:35:06AM -0700, Paul Eggert wrote:
> Erik Auerswald wrote:
> >an explicit "Inf" keyword is still better than some number that
> >relies on system limits
> 
> With the latest patch, there are no system limits; you can use as
> big a number as you like.  I'm aware of the "use 0 to denote
> infinity" tradition, but I'm still leery of using a valid width
> value to denote infinity; I'd rather use some other string.

Numbers between 32 bit SIZE_MAX and 64 bit SIZE_MAX will show
differing behavior between 32 and 64 bit platforms (and data models).
In practice this should be irrelevant, but it might result in very
obscure failures. Explicitly setting the width to infinity, that is
not adding any line breaks, avoides that.

I would not consider 0 to be a valid width value, and the ls command
agrees:

$ ls -w0
ls: invalid line width: 0
$ ls --version | head -n1
ls (GNU coreutils) 8.21

As always, the asked for new command behavior can be achived by a bit
of scripting (be it shell or awk or whatever). I do not even argue that
enabling ls output in a single line is useful, Beco did. I just try to
give another perspective on the request.

IMHO explicitly specifying that no width limit should be assumed is
better than implicitly interpreting some implementation defined range
of numbers as infinity. Beco's suggestion of 0 has precedent and seems
more obvious to me than requiring a special keyword.

I hope this email documents that there are differing views on the matter,
and thank you for reading and considering my point of view.

Erik





reply via email to

[Prev in Thread] Current Thread [Next in Thread]