Thanks for maintaining debian's bash package.

I like it.

The main reason I'm writing is that I noticed
behavior that seems odd, at least to me, and I
want to bring it to your attention in case you
agree that there's a bug.

As you may know, bash is supposed to report:

    "Argument list too long"

after too many arguments are passed to a command.

I'm familiar with this.

However I seem to have found another way to elicit
the same error message: piping a big variable into
grep.

A script that duplicates the behavior is attached.
Most of it is a multi-line command that creates a
big variable. The whole script only has three
commands.

I suggest running the attached script and seeing
if it:

    a.) reports

            "/bin/egrep: /bin/sh: bad interpreter: Argument list too long"

        on your box too, and,

    b.) starts working after deleting almost any byte.

Someone else has already duplicated the behavior.

I look forward to learning what you think,
Kingsley

This behavior is reproducible, as described, but I think it is the
same problem as ls * in a directory with a massive number of
entries.  I expect that echo "$a" is a command with only one argument,
but it is a massive argument.  Argument lists are not meant to be
massive; large inputs should be given on stdin (NOT by echoing
something there!) or via a filename.

Hi Justin,

Thanks for taking the time to reproduce the bug.

I agree that "$a" is massive.

However, it seems to me that the error isn't
reported after the echo command.

A close examination of the error message:

    "/bin/egrep: /bin/sh: bad interpreter: Argument list too long"
          ^^^^^
reveals that it was emitted after being piped into
the stdin of egrep.

I verified that the error isn't reported after the
echo command by changing the last line in the
test script from

    echo "$a" | egrep " is now known as | has joined "

to just

    echo "$a"

which reported no error.

Thanks,
Kingsley

$ type egrep
egrep is /bin/egrep

$ which egrep
/bin/egrep

$ file $(which egrep)
/bin/egrep: Bourne shell script text executable

So, I think this bug is fully understood.  /bin/egrep just calls
grep -E "$@", so if $@ is MAXARGS-1, the -E puts it over the edge.
The error starts with "/bin/egrep" since that is the name of the
command; if you were to mv /bin/{egrep,foo} then it would say
"/bin/foo: /bin/sh: bad interpretter: arg list too long" since it is
being interpretted by /bin/sh.

Can this bug be closed?

Justin

Yes, but, $@ is not anywhere near as big as
MAXARGS.

As you can see below, only seven "arguments" are
passed to egrep.

    echo "$a" | egrep " is now known as | has joined "

The BIG data is piped from $a into egrep's
"standard input" (stdin).

And, oddly, the big data on standard input elicits
an error message about "Argument list too long".

Unless I'm mistaken, it seems to me that the bug
is not understood yet, and this bug report should
stay open.

Am I missing something?

Thanks,
Kingsley

The problem is that ARG_MAX applies to the sum of envp and argv; see
execve(2).  So grep -E is being called with a massive environment.
Try sourcing the script, and then running certain commands..

pryzbyj@andromeda:/tmp$ ls aaaaaaaaaaaaaaaaa
ls: aaaaaaaaaaaaaaaaa: No such file or directory
pryzbyj@andromeda:/tmp$ ls aaaaaaaaaaaaaaaaab
bash: /bin/ls: Argument list too long

Justin

Hmmmm... I didn't know that.

If you're certain that envp is included in the
sum, then shouldn't the error message reflect that
it is?

Thanks,
Kingsley

Did you check the manpage execve?
Its probably a standard unix error text, I'm not sure.  Anyway it is
from libc6, not bash.

Justin

The manpage is also in Debian, manpages-dev, and mentions it.
Of course; anytime a shell does anything external it is with exec; try

  strace /bin/echo foo 2>&1 |head -1
$ strace -f sh ./bug.1.sh 2>&1 |grep exec |tail -1
[pid 24558] execve("/bin/egrep", ["egrep", " is now known as | has
joined "], [/* 26 vars */]) = -1 E2BIG (Argument list too long)
I'm not sure; like I say, this message might be specified by some
standards document, or perhaps just by convention.  It doesn't make
sense to fix it in bash only, since really every application using
exec() would also need to be fixed (see strerror).

Indeed, see this, as downloaded by the 'susv3' nonfree package
file:///usr/share/doc/susv3/susv3/basedefs/errno.h.html#tag_13_10

You can reassign it if you like, but I would argue that existing
documentation is sufficient.

Justin

[...]

OK. It's good to see that the sum is mentioned
somewhere.

[...]

Very good.

[...]

I agree.

[...]

OK

This is where I must disagree.

The error message complains about "arguments", but
the problem is with the "environment". It
inevitably misleads users, especially new users.

It seems to me that

    1.) execve() should return a more precise
    error message that mentions the "environment",
    and

    2.) "Additional error numbers may be defined
    on conforming systems; see the System
    Interfaces volume of IEEE Std 1003.1-2001."
    (See file:///usr/share/doc/susv3/susv3/basedefs/errno.h.html#tag_13_10)

Having said that, thank you for your time and
attention.

All the best,
Kingsley

execve "returns" only an error number, -1 on failure.  If it fails, it
also sets errno to a nonzero value, which is an index into
sys_errlist.
But, I don't know if it will break things or not.

Justin

Lieber Bewerber,

unsere Firma ist ein erfolgreiches, europaweit agierendes Unternehmen und sucht zur Zeit aktive Kollegen zur Verstärkung des Teams europaweit.

Die Dienste werden europaweit gefragt, und Sie haben die Gelegenheit unabhängig von Ihrem Wohnort zu arbeiten. Wir bieten Arbeitsstellen für jeden. Die Arbeitsstelle kann sowohl von Rentnern, Hausfrauen als auch nebenberuflich erledigt werden.
Übersetzungen, Sekretärservice, Begutachter, und vieles mehr wird aktuell angeboten.

Es werden Ihnen mögliche Aufträge und die dazugehörige Bezahlung angeboten und Sie entscheiden sich. Jede Aufgabe wird verschieden vergütet, in der Regel erhalten Sie bei 3-5 Stunden am Arbeitstag 1500 bis 1900 Euro Brutto monatlich.
Sie haben keine Ausgaben und können sofort bei uns einsteigen.

Kennziffer ZZZBW273310210 Es sind 13 freie Positionen zu besetzen.

Die benötigte technische Ausrüstung wird von uns ohne weitere Kosten zur Verfügung gestellt. Die Arbeitsstelle kann gerne von Rentnern, Hausfrauen und auch nebenberuflich ausgeführt werden.
Ihre Voraussetzungen wären verantwortungsvolle, selbstständige Arbeitsweise, Ehrlichkeit, Zielstrebigkeit, Motivation, Leistungsbereitschaft
Wenn wir Ihr Interesse geweckt haben, schicken Sie uns Ihre vollständigen Bewerbungsunterlagen noch heute, gerne per E-Mail an: cecocathoq@australiamail.com Sie erhalten weitere Unterlagen zugeschickt.


Wir freuen uns auf Ihre Antwort.

Hochachtungsvoll

Schoffer SA
Rue de la Grande-Truanderie 55
Malbec 3534