summary refs log tree commit diff
path: root/src/input.c (follow)
Commit message (Collapse)AuthorAge
* [INPUT] Made setinputfd staticHerbert Xu2008-07-13
| | | | | | This function is no longer used anywhere else. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [PARSER] Removed noexpand/length check on eofmarkHerbert Xu2007-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [REDIR] Remove redundant CLOEXEC callsHerbert Xu2007-05-12
| | | | | Now that we're marking file descriptors as CLOEXEC in savefd, we no longer need to close them on exec or in setinputfd.
* [REDIR] Replace copyfd by savefd and use dup2 elsewhereHerbert Xu2007-05-12
| | | | | | | 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.
* [REDIR] Remove EMFILE special caseHerbert Xu2007-05-06
| | | | | 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.
* [PARSER] Only use signed char for syntax arraysHerbert Xu2006-04-23
| | | | | | | | | 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.
* Copyright/licence updates and remove all traces of sys/cdefs.hHerbert Xu2005-10-29
| | | | | | | | | | | 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.
* [INPUT] Size optimisations in preadbuffer()Herbert Xu2005-10-26
| | | | | | | Added unlikely markers. Reduced switch coverage. Removed p since we now erase NULs as soon as we see them. Use more to store parselleft.
* [INPUT] Fix NUL skipping in preadbufferHerbert Xu2005-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Generalise setinputfile for use in read_profile/readcmdfile.herbert2005-09-26
|
* Renamed error to sh_error.herbert2005-09-26
|
* Initial import.Herbert Xu2005-09-26