| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On 27/06/17 16:29, Zando Fardones wrote:
> Hello,
>
> I think I've found a bug when using the here-document redirection in
> an interactive shell. What basically happens is that you can't see the
> command output if you set the "vi" or "emacs" options.
That's not quite what happens: the here-document contents got lost, so
there is no command output to see. Nice find.
The problem is that getprompt() is implicitly called by el_gets(). This
messes with the memory used by the parser to store the here-document's
contents. In the non-emacs/vi case, the prompt is explicitly written by
setprompt(), which wraps the getprompt() call in a
pushstackmark()/popstackmark() pair to restore the state so that parsing
can continue. But when getprompt() is called by el_gets(), it knows
nothing about this.
The whole call to el_gets() can be surrounded by another
pushstackmark()/popstackmark() pair to solve the problem, as attached.
Cheers,
Harald van Dijk
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit ef91d3d6a4c39421fd3a391e02cd82f9f3aee4a8 ([PARSER]
Handle backslash newlines properly after dollar sign) created
cases where we make two consecutive calls to pungetc. As we
don't explicitly support that there are corner cases where you
end up with garbage input leading to undefined behaviour.
This patch adds explicit support for two consecutive calls to
pungetc.
Reported-by: Jilles Tjoelker <jilles@stack.nl>
Reported-by: Juergen Daubert <jue@jue.li>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
| |
Currently we maintain a copy of the input state outside of parsefile.
This is redundant and makes reentrancy difficult. This patch kills
the duplicate global states and now everyone simply uses parsefile.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
| |
It hasn't been possible to build HETIO for over ten years. So
let's just kill it.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
| |
The function preadbuffer should be static as it's only used in
input.c.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
| |
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
| |
pgetc_macro is identical to pgetc except that it's a macro and
pgetc isn't. Since there is very little performance difference
on modern systems it's time to kill pgetc_macro.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch improves LINENO support by storing line numbers in the parse
tree, for commands as well as for function definitions. It makes LINENO
behaves properly when calling functions, and has the added benefit of
improved line numbers in error messages when the last-parsed command is
not the last-executed one. It removes the earlier LINENO support, and
instead sets LINENO from evaltree when a command is executed
Signed-off-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes dash exit with return code 127 instead of 2 if
started as non-interactive shell with a non-existent command_file
specified as argument (or a directory), as documented in
http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html#tag_04_128_14
The wrong exit code was reported by Clint Adams and Jari Aalto through
http://bugs.debian.org/548743
http://bugs.debian.org/548687
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looks like in contrast to what the dash.1 manual page says, expansion
of PS{1,2,4} does work.
Here is a little patch to set LINENO. The ways in that it is less than
ideal mirror the ways that the line number error reporting is also
less than ideal.
For example if you run this:
(
x=$((1/0))
# Just to add another line
# And another
) # error reports this line
The error reported will be the closing parenthesis even though I
think most people would prefer the error to be the one where x was
set.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
| |
When I added savefd we may end up closing stderr if that is how
we get to the tty. This patch fixes by adding a second argument
to indicate what fd should be closed which lets jobs.c get around
the problem.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
| |
This function is no longer used anywhere else.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Tue, Oct 30, 2007 at 04:23:35AM +0000, Oleg Verych wrote:
>
> } 8<<""
> ======================
Actually this (the empty delim) only works with dash by accident.
I've tried bash and pdksh and they both terminate on the first
empty line which is what you would expect rather than EOF. The
real Korn shell does something completely different.
I've fixed this in dash to conform to bash/pdksh.
> In [0] it's stated, that delimiter isn't evaluated (expanded), only
> quoiting must be checked. That if() seems to be completely bogus.
OK I agree. The reason it was there is because the parser would
have already replaced the dollar sign by an internal representation.
I've fixed it properly with this patch.
Test case:
cat <<- $a
OK
$a
cat <<- ""
OK
echo OK
Old result:
dash: Syntax error: Illegal eof marker for << redirection
OK
echo OK
New result:
OK
OK
OK
|
| |
|
|
|
| |
Now that we're marking file descriptors as CLOEXEC in savefd, we no longer
need to close them on exec or in setinputfd.
|
| |
|
|
|
|
|
| |
There are two kinds of users to copyfd, those that want to copy an fd to
an exact value and those that want to move an fd to a value >= 10. The
former can simply use dup2 directly while the latter share a lot of common
code that now constitutes savefd.
|
| |
|
|
|
| |
No caller of copyfd need to ignore EMFILE so we can remove the special
case and just let it call sh_error on any error.
|
| |
|
|
|
|
|
|
|
| |
The existing scheme of using the native char for syntax array indicies
makes cross-compiling difficult. Therefore it makes sense to choose
one specific sign for everyone.
Since signed chars are native to most platforms and i386, it makes more
sense to use that if we are to choose one type for everyone.
|
| |
|
|
|
|
|
|
|
|
|
| |
This change updates the BSD licence to the three-clause version since
NetBSD has already done so. This makes dash GPL-compatible.
It also adds Christos Zoulas (NetBSD ash maintainer) to the COPYING file.
I've added "copyright by Herbert Xu" to most files.
Finally all CVS IDs and inclusion of sys/cdefs.h have been removed.
The latter is needed for support of klibc.
|
| |
|
|
|
|
|
| |
Added unlikely markers.
Reduced switch coverage.
Removed p since we now erase NULs as soon as we see them.
Use more to store parselleft.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Sun, Sep 25, 2005 at 07:50:54PM +0000, Gerrit Pape wrote:
> On Sat, Sep 03, 2005 at 02:56:00PM +0200, Martin Dickopp wrote:
> > When analysing the bug I came to the following conclusion: The loop
> > beginning at input.c:302 overwrites a single input line with itself,
> > skipping NUL characters. Therefore, after the loop the line buffer
> > has less characters than originally read if and only if the input line
> > contains NUL characters.
>
> yes. Thanks a lot for the details and patch.
>
> > The pointer that is used to read from the buffer, 'parsenextc' (cf.
> > input.h:66), is also used as the beginning of the next line in
> > input.c:296. This fails if the buffer contains less characters
> > than originally read into it due to NUL characters.
> >
> > The proposed patch (attached) keeps track of the number of skipped
> > characters and advances 'parsenextc' accordingly before processing
> > the next input line.
>
> Hi Herbert, please see
> http://bugs.debian.org/317516
Instead of moving the characters in the loop, we will do memmove every
time we see a NUL character. This hurts if there are a lot of NUL
characters, but should be a win in normal situations.
|
| | |
|
| | |
|
| |
|