Please add hotfix for bug 8506

2016-05-07 Thread Martijn Dekker
Bug 8506 is a severe ash bug for shell scripts running in UTF-8 locales causing corrupted output of ${#var} if $var contains UTF-8 characters. It is fixed in git but not in the latest release version. So, as per https://busybox.net/fix.html I propose to add the attached patch as a hotfix to

Re: BusyBox for OSX

2016-09-04 Thread Martijn Dekker
Op 31-08-16 om 11:59 schreef casey: > REM’d out that build option in /configs/osx_defconfig: [...] > #CONFIG_EXTRA_CFLAGS=‘-arch x86_64 -mmacosx-version-min=10.5' Your problem here were the curly (non-ASCII) single quotes (‘’). Shells don't understand these. Use the straight ASCII ones ('')

[BUG] Interactive (d)ash exits on assigning to readonly from 'command eval'

2016-10-27 Thread Martijn Dekker
This bug is on both dash and busybox ash. The "command" builtin is supposed to stop special builtins (such as "eval") from exiting the shell on error. So doing something like isreadonly() { ! command eval "$1=" 2>/dev/null } ought to be a way to test if a variable is read-only

Re: 'case' UTF-8 bug

2016-11-23 Thread Martijn Dekker
Op 24-11-16 om 00:14 schreef Denys Vlasenko: > Can't reproduce: [...] > Tried with CONFIG_FEATURE_SH_STANDALONE=y and it still works for me. > > Please send your .config OK, see attached. - M. # # Automatically generated make config: don't edit # Busybox version: 1.25.1 # Wed Nov 23 19:33:33

'case' UTF-8 bug

2016-11-23 Thread Martijn Dekker
busybox ash in UTF-8 locale does not like the lowercase Greek letter 'rho' (CF 81) in a case statement. case "ρ" in ( "ρ" ) echo ok ;; ( * ) echo WRONG ;; esac outputs WRONG. The preceding character π (CF 80) is fine, but the succeeding one ς (CF 82) is not. There are other characters with

Re: [PATCH] ash: fix error code regression

2017-01-06 Thread Martijn Dekker
Op 02-01-17 om 13:50 schreef Ron Yorston: > The commit 'ash,hush: set exit code 127 in "sh /does/not/exist" case' > only partly implemented the dash commit '[ERROR] Allow the originator > of EXERROR to set the exit status'. This resulted in incorrect error > codes for a syntax error: [...]

Re: [BUG] 'eval' returns 0 on error

2017-01-01 Thread Martijn Dekker
Op 23-12-16 om 00:30 schreef Martijn Dekker: > On busybox 1.26.0, 'eval' returns status 0 even if there is a syntax error. > > $ ( eval '(' ) && echo false positive > ./ash: eval: syntax error: unexpected end of file (expecting ")") > false positive > >

Re: 'case' UTF-8 bug

2016-12-24 Thread Martijn Dekker
Op 24-11-16 om 08:22 schreef Denys Vlasenko: > On Thu, Nov 24, 2016 at 2:57 AM, Martijn Dekker <mart...@inlv.org> wrote: >> Op 24-11-16 om 00:14 schreef Denys Vlasenko: >>> Can't reproduce: >> [...] >>> Tried with CONFIG_FEATURE_SH_STANDALONE=y and it still

[BUG] 'eval' returns 0 on error

2016-12-22 Thread Martijn Dekker
On busybox 1.26.0, 'eval' returns status 0 even if there is a syntax error. $ ( eval '(' ) && echo false positive ./ash: eval: syntax error: unexpected end of file (expecting ")") false positive This behaviour does not occur in 1.25.1. Thanks, - M.

Re: [PATCH] quote arguments in xtrace output

2017-03-24 Thread Martijn Dekker
Op 24-03-17 om 17:39 schreef Denys Vlasenko: > IOW: dash is not dead. Bugs were fixed there recently. You know, routing replies to off-list messages back to the list is not really a nice thing to do at all. Yes, it is entirely possible dash development will pick up again. That's why there was no

[PATCH] quote arguments in xtrace output

2017-03-18 Thread Martijn Dekker
The xtrace (set -x) output in ash is a bit of a pain, because arguments containing whitespace aren't quoted. This can make it impossible to tell which bit belongs to which argument: $ ash -x -c 'somevar="one two" printf %s\\n one "two three" four' + somevar=one two printf %s\n one two three four

'trap' builtin: free(): invalid pointer

2017-06-30 Thread Martijn Dekker
The trap builtin produces the following and aborts the shell if you give it an invalid signal number (> 64). Confirmed on Busybox ash down to 1.20.0. $ ./ash -c 'trap - 65' *** glibc detected *** ./busybox: free(): invalid pointer: 0x01ee50e8 *** === Backtrace: =

Re: 'trap' builtin: free(): invalid pointer

2017-07-01 Thread Martijn Dekker
Op 01-07-17 om 13:25 schreef tiggersWelt.net (Support): > I can confirm that this happens on latest git-version and was able to track > this > one down to shell/ash.c, line 12970. > > The attached patch solves the issue. Fix confirmed. Thanks. - M.

Re: 'case' UTF-8 bug

2017-07-02 Thread Martijn Dekker
Op 01-02-17 om 13:27 schreef Denys Vlasenko: > On Sat, Dec 24, 2016 at 2:17 PM, Martijn Dekker <mart...@inlv.org> wrote: >> Op 24-11-16 om 08:22 schreef Denys Vlasenko: >>> On Thu, Nov 24, 2016 at 2:57 AM, Martijn Dekker <mart...@inlv.org> wrote: >>>> O

Re: 'case' UTF-8 bug

2017-07-04 Thread Martijn Dekker
Op 04-07-17 om 19:51 schreef Denys Vlasenko: > You said earlier that environment makes no difference. That was incorrect, sorry about that. > For the locale, > it should make a difference. Can you confirm that after setting > all LC_foo variables to "C" bug does not trigger? Yes, I can confirm

Re: 'case' UTF-8 bug

2017-07-05 Thread Martijn Dekker
Op 05-07-17 om 18:15 schreef Denys Vlasenko: > On Wed, Jul 5, 2017 at 1:50 AM, Martijn Dekker <mart...@inlv.org> wrote: >> Slackware 14.1 (with multilib added): >> >> $ /lib64/libc.so.6 >> GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath

Re: 'case' UTF-8 bug

2017-07-05 Thread Martijn Dekker
Op 05-07-17 om 19:15 schreef Denys Vlasenko: > Fix is in git, please try and let me know how does it work. It fixes the bug I reported, but it introduces a new bug: the presence of a quoted closing square bracket in a pattern (whether it's quoted literally or passed from a variable) causes the

Re: 'case' UTF-8 bug

2017-07-05 Thread Martijn Dekker
Op 05-07-17 om 22:23 schreef Denys Vlasenko: > Fixed in git, please confirm. Confirmed. Thanks, - M. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox

Re: 'case' UTF-8 bug

2017-07-04 Thread Martijn Dekker
Op 04-07-17 om 20:23 schreef Denys Vlasenko: > Ok. I just tested it again, and it works for me. > Let's narrow it down more. My libc is: > > $ /lib64/libc.so.6 > GNU C Library (GNU libc) development release version 2.25.90, by > Roland McGrath et al. > Copyright (C) 2017 Free Software Foundation,

[BUG] 'case' does not match double-quoted backslash

2018-02-12 Thread Martijn Dekker
The following outputs BUG in ash: case "\z" in "\z" ) echo ok ;; * ) echo BUG ;; esac Apparently `case` has trouble matching the "\z" pattern due to the backslash within the double quotes. Quoting it in any other way works. Also, backslash-escaping the backslash within the double quotes is

Re: [BUG] 'case' does not match double-quoted backslash

2018-02-12 Thread Martijn Dekker
Op 13-02-18 om 03:09 schreef Kang-Che Sung: > Just wondering, why using "\z" and not "\\z" ? > The former doesn't seem to be a valid syntax. It is valid, though. See the POSIX specification: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03 ===begin quote===

Re: [BUG] 'case' does not match double-quoted backslash

2018-02-13 Thread Martijn Dekker
Op 13-02-18 om 08:12 schreef dietmar.schind...@manroland-web.com: > Von: Kang-Che Sung > Gesendet: Dienstag, 13. Februar 2018 04:52 >> It says the backslash is special only when followed by the $ ` " \ >> characters. >> That is, \$ \` \" \\ and \ are special, but none of these >> includes the \z

Re: [BUG] 'case' does not match double-quoted backslash

2018-02-14 Thread Martijn Dekker
Op 13-02-18 om 14:44 schreef Denys Vlasenko: > Fixed in git, thanks. As already signaled on the dash list, this introduces a new bug: $ ./ash -c 'foo=a; echo "<${foo#[a\]]}>"' Expected output: <> - M. ___ busybox mailing list busybox@busybox.net