Debian Bug report logs - #666198
ls: add -y option

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ls: add -y option

Date: Thu, 29 Mar 2012 12:50:49 -0400

[Message part 1 (text/plain, inline)]

Package: coreutils
Version: 8.13-3.1
Severity: normal
Tags: patch

Attached patch adds a -y option, which makes ls behave as if "y" is
entered in response to all prompts.

This is needed for compatability with an early form of shar archive
posted to Usenet in the early 80's. There is valuable historical data
to be extracted from these, but they often seem to use this -y option
to ls that is not present in modern versions. I had been puzzled about
this and laboriously editing it out when unsharring old archives, but
then I stumbled on this 30 year delayed post in my olduse.net feed
that explained the mystery option.

> Newsgroups: net.unix-wizards
> Path: utzoo!decvax!pur-ee!davy
> Date: Sun Mar 28 19:56:33 1982
> Subject: Onyx and BBN C machine ls peculiarity
> From: davy
> X-OldUsenet-Modified: added From; converted from A-news; fixed Message-ID; added
> 
> 1
> 2
> 3
> DECVAX 
> 
> A while back I asked for information on ls command-line arguments
> portability. Here are the answers I got:
> 
>         There is such a -y option for several unix systems. I don't know
>         much about it (ls does not ask me many questions), but it is
>         available on the Onyx for sure, and maybe others.
> 
> I also received one account of someone's experience with ls on the BBN C
> machine:
> 
>         My wife has used the Ryan-McFarland UNIX tools on the BBN C machine
>         in  a beginning UNIX class,  and we found no significant departures
>         from  the ls from AT&T. There is a -y option which  avoids  prompts 
>         regarding display of unsafe terminal control characters.
> 
> Thanks to ittvax!cox, pur-ee!sb, and sii!wje
> 
> --Dave Curree
> pur-ee!davy

In this time period, there had recently been press coverage of an early
Unix security flaw, where programmable terminals were exploited through
display of control characters, to get root etc. It was a new and big deal
then, so I think this explains why utilities like ls were trying to filter
them out and this -y switch was added.

This would be a useful option to have in ls for historical compatability.
And if ls ever needs to prompt again, -y will be there to use. Please
apply the attached patch.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  dpkg          1.16.2
ii  install-info  4.13a.dfsg.1-8
ii  libacl1       2.2.51-5
ii  libattr1      1:2.4.46-5
ii  libc6         2.13-27
ii  libselinux1   2.1.9-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

-- 
see shy jo

[yes.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 666198@bugs.debian.org (full text, mbox, reply):

From: Bob Proulx <bob@proulx.com>

To: Joey Hess <joeyh@debian.org>, 666198@bugs.debian.org

Subject: Re: Bug#666198: ls: add -y option

Date: Thu, 29 Mar 2012 13:50:38 -0600

[Message part 1 (text/plain, inline)]

Joey Hess wrote:
> This is needed for compatability with an early form of shar archive
> posted to Usenet in the early 80's. There is valuable historical data
> to be extracted from these, but they often seem to use this -y option
> to ls that is not present in modern versions.

This is an interesting compatibility feature.  As such I agree it has
some merit although how much I don't know.  Put me down as officially
abstaining from that point.  However:

> +  -y                         answer all questions with \"yes\"\n\

If this is implemented I would definitely leave it as an undocumented
option.  There are other purposefully undocumented options in the
coreutils for the reason that we don't want people to use them in new
applications.  If it is documented then certainly people will add it
to new applications thinking that they should and not knowing better
even if we were to extensively document it that they should not.

Therefore this feature, if implemented, I think should *not* have a
help string added for it.  For the purpose for which it is intended,
successful compatibility with old shar files, this isn't needed.  It
would successfully work making all involved happy.

Bob

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 666198-close@bugs.debian.org (full text, mbox, reply):

From: Michael Stone <mstone@debian.org>

To: Joey Hess <joeyh@debian.org>, 666198-close@bugs.debian.org

Subject: Re: Bug#666198: ls: add -y option

Date: Fri, 30 Mar 2012 07:37:16 -0400

On Thu, Mar 29, 2012 at 12:50:49PM -0400, Joey Hess wrote:
>Attached patch adds a -y option, which makes ls behave as if "y" is
>entered in response to all prompts.
>
>This is needed for compatability with an early form of shar archive
>posted to Usenet in the early 80's. There is valuable historical data
>to be extracted from these, but they often seem to use this -y option
>to ls that is not present in modern versions. I had been puzzled about
>this and laboriously editing it out when unsharring old archives, but
>then I stumbled on this 30 year delayed post in my olduse.net feed
>that explained the mystery option.

There is a very strong desire to avoid adding new short options to the 
standard utilities. I do not think adding compatability for old shars 
reaches the bar. (Side note--shars are a good demonstration that not all 
of the industry's bad ideas came from Microsoft. You really want to 
execute obfuscated code downloaded off the internet in order to extract 
a file? My suggestion would be to work on a shar unpacker that can 
extract without executing and also handle different variants.)

Mike Stone

Message #14 received at 666198-done@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: 666198-done@bugs.debian.org, 666244-done@bugs.debian.org, 666684-done@bugs.debian.org, 666688-done@bugs.debian.org

Cc: Bob Proulx <bob@proulx.com>

Subject: Re: Bug#666198: ls: add -y option

Date: Mon, 2 Apr 2012 14:32:20 -0400

Bob Proulx wrote:
> Joey Hess wrote:
> > This is needed for compatability with an early form of shar archive
> > posted to Usenet in the early 80's. There is valuable historical data
> > to be extracted from these, but they often seem to use this -y option
> > to ls that is not present in modern versions.
> 
> This is an interesting compatibility feature.  As such I agree it has
> some merit although how much I don't know.  Put me down as officially
> abstaining from that point.  However:

This was a set up for
http://kitenet.net/~joey/blog/entry/ls:_the_missing_options/

This article http://article.olduse.net/286@Apur-ee.UUCP about COBOL
was edited to create a fairly convincing historical proof of a ls -y.
I think only fairly convincing because it's unclear why a shar would
ever need to ls files, even back in the 80's!

As to the other options, multiple people agree that -e is nearly almost
useful, although none of us can quite find a reason to use it. My bug
report neglected to mention that ls -eR is very buggy. -j is clearly a joke.

-- 
see shy jo

Send a report that this bug log contains spam.