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 htt
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 ('') instea
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 withou
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 thi
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 20
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.
__
Op 24-11-16 om 08:22 schreef Denys Vlasenko:
> On Thu, Nov 24, 2016 at 2:57 AM, Martijn Dekker wrote:
>> 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.
>
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
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:
[...]
Thanks
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
o
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
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: =
/lib64/libc.so
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.
__
Op 01-02-17 om 13:27 schreef Denys Vlasenko:
> On Sat, Dec 24, 2016 at 2:17 PM, Martijn Dekker wrote:
>> Op 24-11-16 om 08:22 schreef Denys Vlasenko:
>>> On Thu, Nov 24, 2016 at 2:57 AM, Martijn Dekker wrote:
>>>> Op 24-11-16 om 00:14 schreef Denys V
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
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,
Op 05-07-17 om 18:15 schreef Denys Vlasenko:
> On Wed, Jul 5, 2017 at 1:50 AM, Martijn Dekker wrote:
>> Slackware 14.1 (with multilib added):
>>
>> $ /lib64/libc.so.6
>> GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et
>> al.
&g
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 pat
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
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
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===
2.
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 y
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
http
Busybox 'find' does not support '--' to signal end of options, as POSIX
requires[*]. (This is the standard way of allowing arguments, in this
case path names, starting with a dash.)
$ ./usr/bin/find -- /dev/null -print
find: unrecognized: --
[long usage message omitted]
Thanks,
- M.
[*] Refe
When listing a symbolic link, the busybox 'ls -id' command incorrectly
lists the inode of the link referred to by the symlink, rather than the
inode of the symlink itself. The -d option is supposed to disable
dereferencing of symbolic links[*].
$ ln -s /bin/ls /tmp/foo
$ _install/bin/ls -id /t
Op 19-12-18 om 20:24 schreef Eli Schwartz:
[...]
The correct way to play this game is to never use -- with find. Its only
POSIX-defined purpose is to be silently ignored.
That's a perfectly fair point. Nevertheless, that purpose is defined by
POSIX so busybox should accept it, if only for the
Op 19-12-18 om 20:47 schreef Martijn Dekker:
Op 19-12-18 om 20:24 schreef Eli Schwartz:
[...]
The correct way to play this game is to never use -- with find. Its only
POSIX-defined purpose is to be silently ignored.
That's a perfectly fair point. Nevertheless, that purpose is defin
$ touch foo
$ cp -a foo foo /tmp/
cp: can't create link '/tmp/foo': No such file or directory
GNU 'cp' just produces a warning and successfully copies the file, but
Busybox 'cp' fails with an error as above and doesn't copy anything.
- m.
___
busybox
Op 19-12-18 om 21:30 schreef Martijn Dekker:
When listing a symbolic link, the busybox 'ls -id' command incorrectly
lists the inode of the link referred to by the symlink, rather than the
inode of the symlink itself. The -d option is supposed to disable
dereferencing of symb
BusyBox 'find' cannot combine '-exec ... {} +' with parenthesis
arguments. This should work.
A simple test case:
$ find /dev/null \( -exec printf '%s\n' {} + \)
$ find /dev/null \( -exec printf '%s\n' {} \; \)
/dev/null
The first command prints nothing with Busybox 'find'; it should print
/de
Commit f3634584 introduced short-form shell options without long-form
equivalents. This broke the output of 'set -o' and 'set +o' as the
function writing this output assumed all options have long names. This
simple patch removes that assumption.
--
modernish -- harness the shell
https://github
Op 03-09-19 om 04:31 schreef Kang-Che Sung:
Excuse me, but I wonder one thing on the third patch: Why should we follow
strictly with gzip on the no-options default behavior?
For two reasons.
First, the default 6 compression level is a de-facto standard. BSD gzip
and Apple gzip (on macOS) use
This is probably the strangest bug (or maybe pair of bugs) I've run into
in nearly five years of breaking shells by developing modernish.
I've traced it to an interaction between bash >= 4.2 (i.e.: bash with
shopt -s lastpipe) and variants of the Almquist shell, at least: dash,
gwsh, Busybox a
33 matches
Mail list logo
