| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the prompt would be expanded every time editline called the
getprompt callback. I think the code may have been written assuming that
editline only calls getprompt once per prompt, but it may actually call
it many times, for instance every time you type backspace. This results
not only in slower editing from expanding complex prompts repeatedly, it
also consumes more and more stack memory each time getprompt is called.
This can be seen by setting PS1 to some command substitution, typing
many characters at the prompt, then holding backspace and observing
memory usage. Thankfully all this stack memory is freed between prompts
by the stackmark calls around el_gets.
This change causes prompt expansion to always happen in the setprompt
call, as it would when editline is disabled, and a cached copy of the
prompt is saved for getprompt to return every time editline calls it.
Since getprompt is no longer doing expansion, the stackmark calls
surrounding el_gets can be removed.
|
| |
|
|
|
|
|
|
|
| |
There are some remaining stat/readdir calls in dash that may lead
to spurious EOVERFLOW errors on 32-bit platforms. This patch changes
them (as well as open(2)) to use the explicit large file API.
Reported-by: Tatsuki Sugiura <sugi@nemui.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With -fno-common, which will be enabled by default in GCC 10, we see
this error:
ld: input.o:(.bss+0x0): multiple definition of `el';
histedit.o:(.bss+0x8): first defined here
To fix this, simply remove the definition as it is not needed.
Signed-off-by: Jeroen Roovers <jer@gentoo.org>
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we enter a subshell we need to drop the saved redirections
as otherwise a subsequent unwindredir could produce incorrect
results.
This patch does this by simply clearing redirlist. While we
could actually free the memory underneath for subshells it isn't
really worth the trouble for now.
In order to ensure that this is done in every place where we enter
a subshell, this patch adds a new mkinit hook called forkreset.
The calls closescript, clear_traps and reset_handler are also added
to the forkreset hook.
This fixes a bug where the first two functions weren't called
if we enter a subshell without forking.
Reported-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
| |
When evalcommand invokes a command that modifies parsefile and
then bails out without popping the file, we need to ensure the
input file is restored so that the shell can continue to execute.
Reported-by: Martijn Dekker <martijn@inlv.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|