backslash
and is not part of a bracket expression produces undefined results.
> This also affects
>
> case [a in [?) echo ok ;; *) echo bad ;; esac
>
> which should print ok.
Even ksh prints bad here.
I would however consider a patch that simplifies the code in the
s).
> For example:
> echo 'a\cb' c; echo d
> shall write "ad" followed by a newline.
Works for me:
$ build/src/dash -c "echo 'a\cb' c; echo d"
ad
$
AFAICS my patch doesn't change \c handling at all. When we hit
\c print_escape_str will return 0x1
so buggy.
Good luck writing a script with an unquoted [ expecting it to be
portable :)
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the
nt I think we should
pretty much give up on POSIX compliance the way it's headed.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash"
On Fri, Sep 02, 2016 at 09:49:53AM -0500, Eric Blake wrote:
> On 09/02/2016 09:29 AM, Herbert Xu wrote:
> > On Fri, Sep 02, 2016 at 09:25:15AM -0500, Eric Blake wrote:
> >>
> >>>> This also affects
> >>>>
> >>>> case [a in [?) ech
h has never worked this way. What's worse is that your patch
changes dash's behaviour in a way that is inconsistent with every
shell out there except bash.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.tx
Reported-by: Olof Johansson
Signed-off-by: Herbert Xu
diff --git a/src/expand.c b/src/expand.c
index 36bea76..2a50830 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -1584,14 +1584,14 @@ pmatch(const char *pattern, const char *string)
p++;
I'm in the process of fixing it. For the time being the git tree
is the best place to get the source code.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the
On Thu, May 11, 2017 at 09:55:46AM -0500, Eduardo Bustamante wrote:
> On Thu, Mar 9, 2017 at 5:41 AM, Herbert Xu
> wrote:
> [...]
> > I'm in the process of fixing it. For the time being the git tree
> > is the best place to get the source code.
>
> Hi H
such as "${var#\[}"
This patch restores the original behaviour for the buggy case
while keeping the naked backslash for the quoted pattern case.
Fixes: 7cfd8be0dc83 ("[EXPAND] Move parse-time quote flag...")
Reported-by: Denys Vlasenko
Suggested-by: Harald van Dijk
Signed
CCTL,CCTL,CCTL,CCTL,
CCTL,CCTL,CCTL,CCTL,
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the b
arser currently does not
understand nested quoting in patterns at all. That is, if your
parameter expansion are within double quotes, then dash at the
parser level will consider the pattern to be double-quoted. Thus
any nested single-quotes will be literals instead of actual quotes.
If we fix this
I'll see if I can get that working.
Yes but that's overkill just to fix single quote within patterns.
We already support nested double-quotes in patterns correctly. As
single quotes cannot nest, it should be an easy fix.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana
ng another local variable, then the parse of the nested ${y-} would
> clobber that variable.
I don't see why that's hard. You just need to remember whether
you're in a pattern context (i.e., after a %/%% or #/##). If you
are, then you need to go back to basesyntax instead of
r, your patch also breaks here-
document parsing when the delimiter is a single backslash.
cat << "\"
\
If you can fix these two problems it should be good to go.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key:
> foo() {
> true
> }
> trap foo EXIT
>
> Fix by properly freeing the trap pointer in exitshell().
>
> Signed-off-by: Andreas Bofjall
This is not needed because we're about to exit so all memory will
be going back to the OS.
Cheer
is imperfect, both false positives
and false negatives can occur.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a
; }
>
> static int
>
> I could use greater resolution in `test -nt` / `test -ot`, and st_mtim
> field is standardized under POSIX.1-2008 (or so stat(2) says).
Sure. But your patch is corrupted.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
cuments. It has to be moved after it. IOW I think
you should leave the pgetc's before CHECKEND as is, which also means
keeping some of the CBACK processing as is.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/p
exact same set of errors to be detected
>> on non-glibc systems.
>
> That makes sense, thanks.
Could you resend your patch with this change please?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
snip]
>> Which is better?
>
> That other patch only fixes it for the unset case, not for the empty
> case, so I think the recent one is better.
Yes, yours is better but please resend it with the ERANGE change
as suggested.
Thanks,
--
Email: Herbert Xu
Home Page:
getc_eatbnl() are conditional
> on syntax!=SQSYNTAX, there shouldn't be a problem. It would be a different
> story if the delimiter could be an unquoted backslash, but thankfully that
> is not possible.
Good point. In that case please resend it with the pgetc2 change
and it should be good to
to go.
This patch also fixes removes any backslashes that precede right
braces when they are present within a parameter expansion context.
The idea of a recursive parser is based on a patch by Harald van
Dijk.
Signed-off-by: Herbert Xu
diff --git a/src/expand.c b/src/expand.c
index 2a50830
On Wed, Mar 07, 2018 at 07:19:56PM +0100, Harald van Dijk wrote:
> On 3/7/18 7:51 AM, Herbert Xu wrote:
> >On Wed, Mar 07, 2018 at 07:49:16AM +0100, Harald van Dijk wrote:
> >>
> >>This was wrong in the original patch, but I'm not seeing it in the updated
>
t this allows us to remove the naked
backslashes for patterns within double-quotes, which means that
EXP_QPAT also has to go.
This patch also fixes removes any backslashes that precede right
braces when they are present within a parameter expansion context.
The idea of a recursive parser is based on
r of other shells
and I think I will stick with my patch's behaviour for now.
In general, if there are disagreements between shells and the
standard is not specific enough, I'll pick the approach that
results in simpler code.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~
On Thu, Mar 08, 2018 at 10:05:01AM +, Martijn Dekker wrote:
> Op 08-03-18 om 07:52 schreef Herbert Xu:
> > This patch should fix this problem as well as the one Harald identified:
>
> Tested. It works well on my end.
>
> Note it leaves one bug Harald's patch fixe
braces when they are present within a parameter expansion context,
and backslashes that precede double quotes within inner double
quotes inside a parameter expansion in a here-document context.
The idea of a recursive parser is based on a patch by Harald van
Dijk.
Signed-off-by: Herbert Xu
diff -
prints * instead of nothing as it should. The problem is that
when we're in sqsyntax context in a here-document, we won't add
CTLESC as we should. This patch fixes it:
Reported-by: Harald van Dijk
Signed-off-by: Herbert Xu
diff --git a/src/parser.c b/src/parser.c
index 3aeb9f6..d86d71e 1
; it hints at being an array or bit mask of pending singnals.
>
> Signed-off-by: Denys Vlasenko
> CC: dash@vger.kernel.org
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscrib
e editing and place sh
> into vi insert mode.
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a m
e is correct, and printing tracked aliases is
> intentional.
>
> If it's desirable to drop that feature, then it should be dropped
> completely, code shouldn't be left in that can no longer be used. But
> it's possible to keep it working: how about this instead?
>
; set +o debug; echo "|$- are the options|"'
> > |
> > |uCf are the options|
>
> This turned out to be easy to fix. The routine producing the "$-"
> expansion failed to skip options for which there is no option letter,
> but only a long-form name
eclared (first use in this function)
> optreset = 1; optind = 1; /* initialize getopt */
> ^~~~
>
> Signed-off-by: Baruch Siach
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
for fnmatch(3) and
> supplies its own implementation if necessary, but fnmatch.h is always
> included.
>
> Let me know what you think.
>
> Regards,
> Rink
>
> Do not assume we can include fnmatch.h
>
> Signed-off-by: Rink Springer
Patch applied. Thanks.
--
Email
te 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.
Patch applied. Thanks.
--
Email:
On Wed, Mar 07, 2018 at 01:03:26PM +, Martijn Dekker wrote:
> Op 07-03-18 om 06:26 schreef Herbert Xu:
> > Martijn Dekker wrote:
> >>
> >>> Since base is always a constant 0 or a constant 10, never a
> >>> user-provided value, the only error that
g backquotes in a here-document EOF mark is broken
because dash tries to do command substitution on it. This patch
fixes it by checking whether we're looking for an EOF mark during
tokenisation.
Reported-by: Harald van Dijk
Signed-off-by: Herbert Xu
diff --git a/src/parser.c b/src/parser.c
in
;< "
"
IOW it's not clear that "word" in this context necessarily follows
the same rules used during normal tokenisation.
Anyway, dash has had CHKEOFMARK since 2007 so this is just an
extension of existing behaviour.
Cheers,
--
Email: Herbert Xu
Home Page: ht
ch you conveniently dismissed :)
> For your example, does any shell, including dash, *not* treat this as a
> multi-line heredoc delimiter consisting of a newline character (which may or
> may not be matched by two blank lines, depending on the shell)?
Yes, almost every shell fails with
it's actually the same reason
as the second, namely newlines are not accepted within parameter
substitution. If we fixed this then it should work correctly.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
On Wed, Mar 07, 2018 at 05:32:29PM +, Martijn Dekker wrote:
> Op 07-03-18 om 15:46 schreef Martijn Dekker:
> > Op 06-03-18 om 09:19 schreef Herbert Xu:
> >> On Thu, Jun 22, 2017 at 10:30:02AM +0200, Petr Skočík wrote:
> >>> would you be willing to pull somethin
me duplicated backslash-newline handling elsewhere in parser.c.
> Replace most of the calls to pgetc() with calls to pgetc_eatbnl() and remove
> the duplicated backslash-newline handling.
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:/
Martijn Dekker wrote:
> Here's a .gitignore file for the convenience of casual git users.
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send
This is actually composed of two bugs. First of all our tracking
of quotemark is wrong so anything after "$@" becomes quoted. Once
we fix that then the problem is that the first space character
after "$@" is not recognised as an IFS.
This patch fixes both.
Signed-off-by:
unquoted
> $@ and $* incorrectly generate one empty field (they should generate no
> fields). Apparently that was a side effect of the above.
Please attach a reproducer as I cannot reproduce this problem.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: ht
On Fri, Mar 16, 2018 at 11:27:22AM +0800, Herbert Xu wrote:
> On Thu, Mar 15, 2018 at 10:49:15PM +0100, Harald van Dijk wrote:
> >
> > Okay, it can be trivially modified to something that does work in other
> > shells (even if it were actually executed), but gets rejected
-8. The licenses are bidirectionally
> compatible. Perhaps UTF-8 support could be ported over in the other
> direction? Maybe Denys Vlanesko could assist.
Well if you can show me the code then I can comment :)
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://go
You're right. The proper fix to this is to ensure that nulonly
is not set in varvalue for $*. It should only be set for $@ when
it's inside double quotes.
In fact there is another bug while we're playing with $@/$*.
When IFS is set to a non-whitespace character such as :, $*
outside quote
ains
GPL code. However, they're small and easy to remove/rewrite.
So I'd prefer not to add any more GPL code if possible.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this l
%2}
>
> This used to print A1 B2 C3, but prints A1 B with your patch.
Hmm, it still does on my machine:
$ build/src/dash
$ unset IFS
$ set -- A1 B2 C3
$ echo ${@%2 C3}
A1 B
$
I'm testing against this commit:
commit c166b718b496da63c4df7a0972df2fc6cd38256b
Author: Herbert Xu
Date: T
On Fri, Mar 23, 2018 at 10:27:20AM +0100, Harald van Dijk wrote:
> On 23/03/2018 10:10, Herbert Xu wrote:
> >On Fri, Mar 23, 2018 at 09:27:37AM +0100, Harald van Dijk wrote:
> >>
> >>Also the above. But it breaks a traditional ash extension:
> >>
> >>
> original $@ bug.
You're right. The proper fix to this is to ensure that nulonly
is not set in varvalue for $*. It should only be set for $@ when
it's inside double quotes.
In fact there is another bug while we're playing with $@/$*.
When IFS is set to a non-whitespace chara
you're interested in implementing that in dash, a relevant test case is
>
> set -- A1 B2 C3
> unset p
> echo ${1%${p+x}${p=?}} ${2%${p+x}${p=?}} ${3%${p+x}${p=?}}
> unset p
> echo ${@%${p+x}${p=?}}
>
> In bash and ksh, this is supposed to print, and does print:
&
re sense.
But that was at the cost of not eliminating empty fields which
violates POSIX.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscrib
s slightly better code.
Signed-off-by: Herbert Xu
diff --git a/src/bltin/printf.c b/src/bltin/printf.c
index ec7c8c2..eaf14b6 100644
--- a/src/bltin/printf.c
+++ b/src/bltin/printf.c
@@ -98,20 +98,25 @@ static int print_escape_str(const char *f, int *param, int
*array, char *s)
Currently echocmd uses print_escape_str to do everything apart
from printing the spaces/newlines separating its arguments. This
patch moves the actual printing into print_escape_str as well
using the format parameter.
Signed-off-by: Herbert Xu
diff --git a/src/bltin/printf.c b/src/bltin
It's been a while since we disabled glob(3) support by default.
It appears to be working now, however, we have to change our
code to remove a workaround that now actually prevents it from
working.
In particular, we no longer use GLOB_NOMAGIC or test GLOB_MAGCHAR.
Signed-off-by: Herbert Xu
patch fixes both problems by calling realloc when necessary.
Signed-off-by: Herbert Xu
diff --git a/src/expand.c b/src/expand.c
index 705fef7..dadac56 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -124,7 +124,7 @@ STATIC void expandmeta(struct strlist *, int);
#ifdef HAVE_GLOB
STATIC void
ld otherwise require nasty hacks to work around:
https://sourceware.org/bugzilla/show_bug.cgi?id=866
So I'll give it some time to filter through before trying it again.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au
s.
Well the fact is that all systems allow paths to exist which are
longer than PATH_MAX. Besides, even if we did impose a limit here
we'd still have to check that limit at every recursion level which
means that the code won't be that much simpler.
Cheers,
--
Email: Herbert Xu
Home Pag
me);
> + expmeta1(expdir, p, endname);
> }
> }
> +toolong: ;
> }
> closedir(dirp);
> if (! atend)
> endname[-esc - 1] = esc ? '\\' : '/';
> }
Thanks,
--
Email: Herbert Xu
Home
On Mon, Mar 26, 2018 at 08:19:02AM +0200, Harald van Dijk wrote:
> On 3/26/18 7:12 AM, Herbert Xu wrote:
> >FWIW your patch when built with -O2 with gcc 4.7.2 is actually
> >16 bytes bigger than my version.
>
> Interesting. Not sure what might cause that.
gcc likes to unro
On Mon, Mar 26, 2018 at 12:27:41AM +0800, Herbert Xu wrote:
>
> I tried making it work, and it looks like it should work with
> the latest glibc as they have just fixed a critical issue that
> would otherwise require nasty hacks to work around:
>
> https://sourc
The noclobber code has a typo in it that causes it to fail. This
patch fixes it.
Reported-by: Denys Vlasenko
Signed-off-by: Herbert Xu
diff --git a/src/redir.c b/src/redir.c
index f96a76b..71b0f77 100644
--- a/src/redir.c
+++ b/src/redir.c
@@ -192,7 +192,7 @@ openredirect(union node *redir
me, I don't see how that could work performance
wise.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message
and function.
Reported-by: Denys Vlasenko
Signed-off-by: Herbert Xu
diff --git a/src/eval.c b/src/eval.c
index 7498f9d..19e06ec 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -848,6 +848,8 @@ bail:
goto out;
}
+ jp = NULL;
+
/* Execute the command
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
Signed-off-by: Herbert Xu
diff --git a/src/eval.c b/src/eval.c
index
k to dash yes I think we should adopt the bash behaviour
for pathname expansion and keep the existing case semantics.
This patch does exactly that. Note that this patch does not work
unless you have already applied
https://patchwork.kernel.org/patch/10306507/
because otherwise the opt
he same results anyway. If that
> stops, then checking the file system for matches becomes required.
It doesn't disallow it either. Can you show me a shell that doesn't
apply this optimisation?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: ht
y have broken POSIX because they always treat backslashes that
arise from parameter expansion as literal backslashes.
FWIW it wouldn't be hard to iron out the anomalous case of /d\ev.
You just have treat the backslash as a metacharacter.
Cheers,
--
Email: Herbert Xu
Home Page: http://gon
ould have already been removed by preglob so there should be no
difference.
The only problem with the metacharacter approach is that glibc's
glob(3) probably won't treat it as a metacharacter and therefore
it will still behave in the same way as the current bash.
Cheers,
--
Email: Herbert X
ide to enable
> --enable-glob by default in the future. As long as you don't include
> GLOB_NOESCAPE, then normally, it should be taken as escaping the next
> character, but it might still trigger GLOB_NOMAGIC to return early. If it
> does, I'd take that as a glibc bug, but
eta
> character.
Oh I though you were talking about test/[, I didn't see the set.
But why would someone do set "["?
> Then, how about moving some of expmeta()'s checks to return early outside of
> it, so that they can also be done in the glob() case?
We could.
Cheers
o just drop the /d\ev issue and use the bash
behaviour until such a time that bash changes or POSIX changes.
It's such an unlikely case as why would anyone knowingly put
backslash into a variable and expecting pathname expansion to
remove it without actually using real magic characters.
Cheer
ented it.
$ ksh -c 'a="/usr/bin/\["; printf "%s\n" $a'
/usr/bin/\[
$
If you really wanted to do this in a script, the portable way is
$ ksh -c 'a="/usr/bin/[[]"; printf "%s\n" $a'
/usr/bin/[
$
Cheers,
--
Email: Herbert Xu
Home Page: http://
emoval is not done on the portion of the word that results
from parameter expansion.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
th
unquoted, it
> becomes possible for the next character to be the terminating '\0'.
This code has always had to deal with naked backslashes. Can you
show me the exact pattern that results in the overread?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.a
er shells as a
> reason for not doing it properly.
It's logical for dash because this aligns the behaviour of pathname
expansion with case pattern matching.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.t
On Wed, Mar 28, 2018 at 09:38:04AM +0200, Harald van Dijk wrote:
>
> Also, it's just as logical to restore the case pattern matching to its
> traditional behaviour to align it with pathname expansion.
No I think that makes no sense and clearly contradicts POSIX.
Cheers,
--
Ema
On Wed, Mar 28, 2018 at 08:44:28AM +0200, Harald van Dijk wrote:
>
> Test case:
>
> $v='*\'
> set -- $v
I don't see how this would cause an overrun, can you please explain
it for me?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.
} while (*p++);
@@ -1349,7 +1348,7 @@ expmeta(char *name, unsigned name_len, unsigned
expdir_len)
if (name < start) {
p = name;
do {
- if (*p == '\\')
+ if (*p == '\\' && p[1
\; case \\ in $v) echo bug;; esac
>
> bash prints nothing, dash 0.5.9.1 prints bug. Other shells don't count since
> they interpret $v differently.
Indeed bash seems to do something different for case matches.
Since bash itself is inconsistent, and POSIX unclear, I have opted
to be cons
is no way to actually produce an unescaped backslash
in these shells.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body
ehaviour
is inconsistent at best.
So at this point I am not going to change long-standing dash
behaviour on the unescaped backslash at the end of a pattern.
If and when other shells move on this issue then we can reexamine
this.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au
On Sun, Apr 01, 2018 at 04:34:49PM +0200, Denys Vlasenko wrote:
> Hi Herbert,
>
> Regarding:
>
> commit c166b718b496da63c4df7a0972df2fc6cd38256b
> Author: Herbert Xu
> Date: Thu Mar 15 18:27:30 2018 +0800
>
> parser: Fix backquote support in here-document EO
han during parsing.
Fixes: 3df3edd13389 ("[PARSER] Report substition errors at...")
Signed-off-by: Herbert Xu
diff --git a/src/parser.c b/src/parser.c
index 6a8a4a4..efa8060 100644
--- a/src/parser.c
+++ b/src/parser.c
@@ -1262,7 +1262,7 @@ varname:
look for ENDVAR while innerdq is true.
echo "${x#"${x+''}"''}
This patch fixes it by pushing the syntax stack if innerdq is
true and we enter a new parameter expansion.
This patch also fixes a corner case where a bad substitution error
occurs within ari
-\`-\--\z-\*-\?-
>
> (Second and third line have \t expanded to tab. Mail-mangled to spaces,
> likely)
>
> Apart from \t, note that in second heredoc line there is a difference in how
> `echo '\"'` was handled: bash prints \", dash prints ".
FWIW ksh93
\n
Write a .
\r
Write a .
\t
Write a .
\v
Write a .
\\
Write a character.
\0num
Write an 8-bit value that is the zero, one, two, or three-digit
octal number num.
Cheers,
--
Email: Herbert Xu
I have considered the exporting the variables during the function
execution but have decided against it because:
1) It makes the code bigger.
2) dash has never done this in the past.
3) You cannot use this portably anyway.
Reported-by: Dirk Fieldhouse
Signed-off-by: Herbert Xu
diff --
gt; I think it should retain \" as \".
It wasn't the backquote that removed the backslash but the here-
document. This is expected behaviour as here-documents behave
like double quotes so the backslash is indeed special when it
precedes a double quote.
As I said ksh93 does the same
h is already gone so the
double quote becomes an actual double quote rather than a literal
one.
This is how it works in ksh93 too.
If you want to have guarantee a literal backslash inside a here-
document then you should always do \\.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor
's not relevant.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majord...@vger.kernel.org
More majordomo in
e. So that means no features unless absolutely necessary.
As such I cannot accept this patch as it is.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubsc
. So let's keep it around for now until we
get things such as `jobs -p` to work.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash"
uot;}
> ---
>
> dash will output the following error:
> ./test.sh: Syntax error: Unterminated quoted string
Sorry, I was a bit slack in pushing out the pending patches. It
should be fixed in the git tree now.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.
see and, if the warning text is to be believed, then
> the warning will eventually become an error.
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the li
if
>> you all are happy enough to keep it 'as is', or can resubmit if you
>> think it's warranted.
>
> I think the simple fact that it came up here is evidence that this is
> too jargony for a manual. Patch attached.
Patch applied. Thanks.
--
Email: Herber
On Thu, Apr 19, 2018 at 02:47:42PM +0200, Martijn Dekker wrote:
>
> Would you accept it if it were a configure option, disabled by default (like
> linking with libedit)?
Sorry, I don't think this particular feature would fit well with
a configuration option.
Cheers,
--
Email: He
301 - 400 of 581 matches
Mail list logo
