Re: mksh fails to build
Followup-To: miros-mksh list (which includes miros-discuss list) Andrew Kudryashov dixit: cc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 Use a different version of the compiler. The workaround I applied to the Debian packages is not really ripe for consumption, and relies on the user TESTING THE BINARY BEFORE USING, as it disables the compile-time sanity check that is ABSOLUTELY REQUIRED. If you still want to go on with this broken compiler (will report the issue upstream once I get healthy again), continue: Qrsvar ZXFU_TPP565048 va PCCSYNTF, gura ohvyq ntnva. Nsgrejneqf, qb eha gur grfgfhvgr, ./grfg.fu -i nevgu-znaqngbel ng gur IREL yrnfg. Vs guvf grfg qbrf abg cnff, GUEBJ NJNL GUR OVANEL naq hfr n qvssrerag pbzcvyre. V zrna vg. Vg’f n fnsrthneq ntnvafg n pbz- cvyre srngher bire-bcgvzvfvat guvatf njnl gung zxfu thnenagrrf gb gur fpevcgf vg ehaf, ohg juvpu vf abg cneg bs VFB P99 fgnaqneq abeznyyl, rira gubhtu nyy abezny PCHf abjnqnlf orunir yvxr gung. V ercrng, jvgubhg guvf fnsrthneq, gur erfhygvat ovanel ZHFG ABG or pnyyrq zxfu. Ernyyl. The safer way is to install e.g. gcc-4.6 from precise into your quantal system and use that to build mksh. (On Debian, at least, TenDRA and tcc also work. I’ve also used SUNWcc, but that’s not packaged, and pcc, which needs work for Multi-Arch.) This is https://bugs.launchpad.net/bugs/1058035 by the way. bye, //mirabilos -- Natureshadow Dann mach ich git annex copy --to shore und fertig ist das Natureshadow das ist ja viel cooler als ownCloud ... mirabilos sag ich doch Natureshadow ja wieso stimmt das denn immer was du sagst ...
Re: mksh patch
Andrew Kudryashov dixit: Attached is a hackish workaround for small completion bug that leaves glob noise if non-existent file is matched and tilde expansion is performed at the same time. OK, thanks for the problem analysis and first draft of a fix. You were fully correct, but I could solve it reusing existing code for a similar problem when multiple files were globbed (the many-backslashes issue), with no further regressions. Committed revision 10050843FC3294E3ACD. I also updated both manpage and mailing list (source code; the versions available in the ’net will be synched later automatically) with the new mailing list. bye, //mirabilos -- Natureshadow Oh, ich hab mim Bauch Mittelklick gemacht, als ich nach dem Kaffee gegriffen habe… mirabilos Cool, ich hab ne neue eMail-Signatur Natureshadow Sag doch sowas nich, wenn ich den Kaffee in der Hand habe! Gib mir nen Lappen! Schnell! Das kommt aber nicht mit in die Signatur!
Re: Really strange behaviour or even a bug in MKSH
Carsten Peter dixit:
After running myscript.ksh my shell console seems to be smashed. No
carriage return seems to be done anymore when pressing the return key.
Any characters entered on the shell prompt aren't shown anymore too.
This doesn’t happen for me, even on GNU/Linux at work.
On the other hand, I do not have access to the exact
version of Horracle Linux, so if you could point me to
where I can get the RPM and possibly SRPM in question…
also, #!/bin/ksh may call ATT ksh93, not mksh, depending
on your distribution’s and your own configuration.
Please echo $KSH_VERSION in the script, and possibly,
also ${.sh.version} (syntax error in mksh, works in ksh93).
Thanks,
//mirabilos
--
16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Re: Really strange behaviour or even a bug in MKSH
Roy Tam dixit: I installed the RPM from the Oracle Linux 6.1 ISO image named mksh-39-5.el6.x86_64.rpm. I also tried to install a newer version of Well… I don’t have that. I assume it’s RHEL based, but then, I don’t have that either. So if you could please point me to ideally the SRPM and binary RPM… MKSH today (mksh-40i-0.fc18.20120630.x86_64.rpm) but this requires You can also get a CentOS 6 build of mksh-current from the OpenSuSE buildservice, which is where I let my own RPM variant be compiled for several Linucēs. new versions of (at least) glic so I cancelled the installation as I don't want to screw up anything. ;-) Right. That one’s not for the long-term/enterprise OSes. R39 is ancient! Right, but that doesn’t prevent me from fixing stable mksh versions in released long-term/enterprise OSes, unless they rhyme on the african word for I can’t configure Debian ☺ Their users typically aren’t even allowed to upgrade or worse, compile by themselves. bye, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh
please test mksh-current (was Re: CVS: herc.mirbsd.org: src)
Dixi quod… as I’m not likely to continue hacking tonight Plan is to add tty_fd tracking (so COLUMNS and LINES are continuously updated, even in scripts such as uhr, without the need to use stty), test, then release R41. SO PLEASE TEST! This includes HP-UX, OSF/1, ULTRIX, and many more. Thanks, //mirabilos -- 21:12⎜Vutral sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜Vutral:#MirBSD linux war früher auch mal besser :D
Re: R41c: ^C is propagated all along the session
Steffen Daode Nurpmeso dixit: But we're deep in a very complicated program, right? Right. I thought about digging into and sending patches for - no tab completion over / boundary in upward direction Eh, *what*? - no tab completion in the middle of a word (for partial word before cursor) That’s by design. If you’re in the middle of a word, it’ll still complete the whole word. I find it appalling that e.g. GNU bash doesn’t work that way. You get the partial behaviour by inserting a space (temporarily). - jobs names hard cut to ridiculous size (should at least be START..END, not STARTUNTILCUT, for, e.g., playing music or having multiple jobs which read RFCs) It’s pretty hard to do this well. Additionally, there are some memory constraints *and* terminal sizes come into play… but your improvement idea is noted and gives me some ideas; I know where and what to change, for this. - when traversing history, the terminal width should be fully used; i.e., if a line has 88 characters only 8 characters are shown, which often results in the need to jump to the front to see the exact command... Yeah, the positioning algorithm is nōntrivial and sometimes pretty annoying. That’s in the Emacs part in edit.c FWIW. No good ideas about that one. But this seems to be pretty condensed: Huh, this doesn’t say me anything. Best is really to try to get the people who develop (a)sh and (pd)ksh on NetBSD® to give hints. Benny, Ádám, you’re called as well! ☺ bye, //mirabilos -- „nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist eine Plattform für Einzelkämpfer“ -- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann
Re: R41c: ^C is propagated all along the session
Steffen Daode Nurpmeso dixit: ok for a login shell to simply ignore them; just as mksh(1) R40 did ? ;) There were no signal handling related changes since R40, at least none in that area. bye, //mirabilos -- „nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist eine Plattform für Einzelkämpfer“ -- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann
Re: More fun with IFS
Dan Douglas dixit:
For $@ that sounds about right. I think it would be preferable if x=$@ and
x=$@ were the same. If a user wants IFS-delimited they should probably use
Turns out you’ll get them being the same:
• foo $@ uses the unquoted $@ inside a quoted string,
not the quoted $@, interpretation, because here document
separators (which here strings are handled as) are special
• it’s impossible to treat x=$@ and for x in $@ differently
because the expansion subroutine cannot know it’s being used
to generate a scalar (because the for x in also generates a
scalar but then applies IFS splitting to it)
Patch attached, it breaks IFS-colon-1 regression test. With this
and my earlier interpretation of the standard and its omissions,
I’ll keep the current behaviour of mksh instead (and in the future,
${foo[@]@Q} will get special treatment instead of just a “DDTT”
when someone uses IFS with it, we’ll see). Note that passing whole
arrays in mksh will, eventually, use JSON natively.
bye,
//mirabilos
--
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
mal ein Korn findet, bzw. – in diesem Fall – Recht haben kannIndex: check.t
===
RCS file: /cvs/src/bin/mksh/check.t,v
retrieving revision 1.599
diff -u -p -r1.599 check.t
--- check.t 24 Feb 2013 14:22:41 - 1.599
+++ check.t 5 Mar 2013 16:07:35 -
@@ -3454,6 +3454,43 @@ expected-stdout:
3 A B C
4 A B C
---
+name: IFS-colon-2
+description:
+ Complex test, IFS=:, with $* and $@ in all variants
+stdin:
+ function expassign {
+ typeset -a a
+ a=($@)
+ typeset var asn
+
+ while IFS= read -r asn; do
+ IFS=: command eval $asn
+ #printf '%-14s... %s\n' $asn $var
+ typeset -L14 f=$asn; print -r -- $f... $var
+ done \EOF
+ var=${a[*]}
+ var=${a[*]}
+ var=$*
+ var=$*
+ var=${a[@]}
+ var=${a[@]}
+ var=$@
+ var=$@
+ EOF
+ }
+
+ ${ZSH_VERSION+:} false emulate ksh
+ expassign one:::two three:::four
+expected-stdout:
+ var=${a[*]} ... one:::two:three:::four
+ var=${a[*]} ... one:::two:three:::four
+ var=$*... one:::two:three:::four
+ var=$* ... one:::two:three:::four
+ var=${a[@]} ... one:::two:three:::four
+ var=${a[@]} ... one:::two three:::four
+ var=$@... one:::two:three:::four
+ var=$@ ... one:::two three:::four
+---
name: IFS-null-1
description:
Simple test, IFS=
Index: eval.c
===
RCS file: /cvs/src/bin/mksh/eval.c,v
retrieving revision 1.137
diff -u -p -r1.137 eval.c
--- eval.c 23 Feb 2013 20:03:30 - 1.137
+++ eval.c 5 Mar 2013 16:07:35 -
@@ -865,6 +865,8 @@ expand(
/* terminate word for $@ */
type = XARGSEP;
quote = 0;
+ /* always space-separate words */
+ c = ' ';
}
}
break;
Re: mksh tips
Hugues Moretto-Viry dixit:
If you have enough time, I would appreciate it.
Sure, no problem.
The PS1 included in the previous email ends with \e[0m. As you said it, the
changes are small.
I also added a little description, maybe you'll need it.
OK ;-)
PS: Feel free to re-bounce these mails to the mailing list,
there’s nothing private in here I guess.
How can I do that? I have to send the mails to miros-discuss too?
miros-mksh actually, but yes. If you agree, I’ll just bounce these
past messages to that list as well.
The converted PS1, with ESC [ 0 m at the end, is thus:
PS1=$'\a\r\a\e[1;34m\a┌─| \a\e[36m\a${USER:=$(ulimit -c 0; \
id -un 2/dev/null || echo \?)}\a\e[34m\a |──| \a\e[0;33m\a$(
local d=${PWD:-?} p=~
[[ $p = ?(*/) ]] || d=${d/#$p/~}
print -nr -- $d
)\a\e[1;34m\a |\n└─| \a\e[32m\a$(date +%H:%M)\a\e[34m\a |─\a\e[0m\a '
You might also like this variant:
PS1=$'\a\r\a\e[1;34m\a┌─┤ \a\e[36m\a${USER:=$(ulimit -c 0; \
id -un 2/dev/null || echo \?)}\a\e[34m\a ├──┤ \a\e[0;33m\a$(
local d=${PWD:-?} p=~
[[ $p = ?(*/) ]] || d=${d/#$p/~}
print -nr -- $d
)\a\e[1;34m\a │\n└─┤ \a\e[32m\a$(date +%H:%M)\a\e[34m\a ├─»\a\e[0m\a '
There’s also ↠ or ⇾ or ‣ or ➔ or ➙ or ➛ or ➜ or ➝ or ➞ or ➟
or ➢/➣/➤ or ➨ or ➩ or ➳ or ➸ or ➼ or ➾ or ▶ or ▷ or lots of
other Unicode/UTF-8 characters you could use… people call
me “Mr. WTF-8” for a reason ☺
If you have tmpfs on ${TMPDIR:-/tmp} then you can use this
with mksh R43 or newer:
PS1=$'\a\r\a\e[1;34m\a┌─| \a\e[36m\a${USER:=$(ulimit -c 0; \
id -un 2/dev/null || echo \?)}\a\e[34m\a |──| \a\e[0;33m\a${
local e=$? d=${PWD:-?} p=~
[[ $p = ?(*/) ]] || d=${d/#$p/~}
print -nr -- $d
return $e
}\a\e[1;34m\a |\n└─| \a\e[32m\a${
local e=$?
date +%H:%M
return $e
}\a\e[34m\a |─\a\e[0m\a '
This saves two fork() calls at the expense of tmpfile
creation (the extra 'local e=$?' and 'return $e' are
necessary because these subcommands are run in the
same context as the shell, so an 'echo $?' on the
command line will keep working).
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” -- Tonnerre, psychoschlumpf and myself in #nosec
Re: mksh tips
Hugues Moretto-Viry dixit: Your PS1 conversion was useful. I tried it but now it says above my PS1: mksh: read-only: read-only what? set -x might help. If I understand correctly, the bash syntax \[\e[1;34m\] is replaced in mksh by: \a\e[1;34m\a. Not exactly… About blackslash expansions (\r, \a and \1), it's like bash or not (as described in the link[1])? I think that link actually describes precisely what mksh implements (but would have to look; \U is limited to the BMP and thus pointless though), but… … \a doesn’t substitute \[ and \] in GNU bash, it’s more like this: the prompt is wrapped in $'…' (not just '…') so the shell doesn’t even *see* those escapes when interpolating PS1. But the presence of \r as the *second* octet in $PS1 makes the *first* octet (here, I used \a for readability/easiness) the “flip-flop visibility” character. (This hack was in the original ATT ksh88, actually.) So basically, whenever the shell sees \r as *second* char in PS1, it takes note of the *first* one, and then uses the *third* one and forward as prompt, toggling counting of (multibyte) character widths on/off whenever the char noted earlier occurs, with the stream defaulting to on (counted for prompt length). In mksh, since a few versions, the “toggle” character is not printed, either. Thank you for taking time to reply till now. Gratitude. You’re welcome! bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 180 (194) IN, 79 (84) MW, 0 (0) FP) ‣ src:dash (84 (98) bugs: 3 RC, 39 (43) IN, 42 (52) MW, 0 FP) ‣ src:mksh (1 bug: 0 RC, 0 IN, 1 MW, 0 FP, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
Re: mksh tips
Hugues Moretto-Viry dixit:
First, sorry for the empty message but new Google message interface is
pissing me off...
Ah, best to avoid Google altogether…
About set -x, here a more verbose output:
+ typeset d=/home/mad p=~[[ = ?(*/) ]]
mksh: read-only:
Okay, I see.
You did the mistake of ignoring the newlines I put into the PS1
rendition. I did some of them for readability, but some were
necessary (and some were backslash-escaped even, which need
specific treatment were you to collapse the lines).
If you really want a minimum form (one line), use this:
PS1=$'\a\r\a\e[1;34m\a┌─| \a\e[36m\a${USER:=$(ulimit -c 0; id -un 2/dev/null
|| echo \?)}\a\e[34m\a |──| \a\e[0;33m\a$(local d=${PWD:-?} p=~; [[ $p = ?(*/)
]] || d=${d/#$p/~}; print -nr -- $d)\a\e[1;34m\a |\n└─| \a\e[32m\a$(date
+%H:%M)\a\e[34m\a |─\a\e[0m\a '
If your Google webinterface does not let you read that cleanly,
go to http://news.gmane.org/gmane.os.miros.mksh (they also have
a Usenet/NNTP interface which lets you get the message in its
pristine original form).
bye,
//mirabilos
--
08:05⎜XTaran:#grml mika: Does grml have an tool to read Apple
⎜System Log (asl) files? :)
08:08⎜ft:#grml yeah. /bin/rm. ;) 08:09⎜mrud:#grml hexdump -C
08:31⎜XTaran:#grml ft, mrud: *g*
Re: mksh: first impressions
Finn Thain dixit: For some time I have been meaning to check out mksh, and your email prompted me to install it. The first thing I noticed was how good the documentation is (the bash man page is missing a lot of stuff). Great! Most of the manual page was not written by me, mind you, standing on the shoulders of giants and all that, but still appreciated. I played around with mksh for a while and noticed some other differences with bash. Parameter assignment using here-docs is a nice feature. Another difference is double logical complement. The mksh result was the one I was expecting -- Ouch @bash. Well yes, it does have some odd corners, but this one is definitely unexpected. Another difference is parameter assignment -- […] $ a=foo exec /dev/stdin I think this is a known POSIX violation in GNU bash (though, some of those can be worked around by putting it into POSIX mode); ormaaj can probably say more on that if interested. The mksh man page says, the assignments are in effect only for the duration of the command. In bash you might do, Yes, that’s POSIX-mandated for special builtin utilities or somesuch-worded. So is : a NOP, or is it a builtin command? Beats me! “:” is a builtin utility and the same as “true”, except that “:” is “a POSIX special builtin” and “true” is “a POSIX regular builtin” (see mkshbuiltins[] in funcs.c). Anyway, I'm picking nits. Here's where the rubber hits the road: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12457 fthain20 0 3524 1872 1572 S 0.0 0.1 0:00.01 bash 12734 fthain20 0 2228 712 608 S 0.0 0.0 0:00.00 mksh $ ls -l /bin/mksh /bin/bash -rwxr-xr-x 1 root root 263860 Mar 29 12:51 /bin/mksh -rwxr-xr-x 1 root root 720796 Sep 3 2012 /bin/bash Don’t forget that GNU bash is probably dynamically linked against libreadline and libncurses/libtermcap to boot. Oh, and try mksh-static (on Debian) or roll your own; on a Linux target, klibc (though you’ll need version 2.x to get some bugfixes), dietlibc and bionic are all valid targets (not µClibc, but that’s because it’s a horrid bloated mess, not unlike (e)glibc itself). Just make sure it passes the mksh testsuite (which is a good testsuite for the compiler/toolchain/libc used, too – it finds more bugs in those than in mksh; a recent example can be seen at https://bugzilla.redhat.com/show_bug.cgi?id=922974 in GCC, which is a known repeat offender). Even without -DMKSH_SMALL it’s great – plus, not having to do all the relocation and other stuff involved in dynamic linking, there’s benefit, for example in the amount of CPU instructions required to just run $SHELL -c true; read up on http://k1024.org/~iusty/blog/entry/perf-null/ in case you’re interested; tl;dr in cycles/instructions for shells: bash 1680/1044K mksh 1258/942K dash 766/469K mksh-static 502/322K (though with -DMKSH_SMALL), and that was before my optimisations based on those numbers (e.g. I did get the number of branch misses down *a lot*, as well as the number of cycles for mksh-static. So thanks for the excellent work! You’re welcome! bye, //mirabilos -- [DJBDNS Zone] TTL 86400 – Natureshadow kann man da auch 1d schreiben? mirabilos nö, außerdem kann ein Deutscher oder ein Japaner mit 1d ja erstmal nix anfangen, oder könntest du 1日 im zone file lesen? Natureshadow das heißt für mich: ein Regal, das u.U. schiefstehen könnte
[ANN] mksh R45
Hi everyone, I seem to recall promising an eMail whenever a new release of mksh is out. Et voilà, enjoy “doch!”: https://www.mirbsd.org/permalinks/wlog-10_e20130426-tg.htm I’ve uploaded it to The MirPorts Framework, the OpenSuSE Buildservice and Debian unstable already. I guess raring people are one day too late :þ Please, pretty please with strawberry on top, double-check the results of this mksh release. I’ve not tried all 2⁶⁴ possible inputs for all of the new operations (or all of the old ones, or double that set by including lksh, and on LP64 systems). While I’m, by now, fairly certain that mksh R45 calculates correctly, in both signed and unsigned operations, and sometimes even more so than previous versions, and that lksh is still doing… as well as it’s designed to…, humans can make mistakes. R44 is the new stable series, everything else is now obsolete. I’ve not opened a branch for it yet, as I hope that HEAD will work out well and have nothing urgent queued. bye, //mirabilos -- mirabilos│ untested Natureshadow │ tut natürlich Natureshadow │ was auch sonst ... mirabilos│ fijn ☺
Re: [dev] System shell for sta.li
Anselm R Garbe dixit:
Can you elaborate on this functionality a bit that mksh provides, but
pdksh doesn't?
Not easily; the last release of pdksh was in 1999, and mksh is
actively developed; even pointing out every single bugfix, for
POSuX compliance or genuine, would take several Kibibytes.
It’s developed with an attitude I’d call “suckless”, without
being part of suckless.org though. (And it’s quality software
from Germany ☺) mksh’s even got some sort of community (with
people porting to even more weird platforms than I tried myself,
users sending bugfixes, even developers of other shells jumping
in every once in a while), mostly in IRC but also on a “faux”
mailing list (Cc'd). It’s packaged for almost any modern OS with
the exception of OpenBSD, who don’t like my nose or something.
https://www.mirbsd.org/mksh.htm#clog is the starting point for
a changelog (it begins with the most recent versions but links
to mksh_old.htm#clog for older ones). The HTML source for just
the changelogs (both) is 114 KiB in 1741 hand-written lines…
Basically: if you’re considering a pdksh derivate, there is no
excuse to not use mksh, right now. Even Google Android uses it
as /system/bin/sh; it’s the system shell on MirBSD, FreeWRT and
MidnightBSD as well; I’ve run systems with mksh as /bin/sh on
NetBSD (1.6 onwards, 1.5 is incompatible), Debian, even Kubuntu…
Han Boetes has run Crux Linux with only mksh installed too.
Specific features that are not bugfixes:
• portable (with fun targets such as ULTRIX, Minix-vmd, etc.)
and low number of imports (no stdio or other bloat) with
active support for static linkage
• implements some extensions that ATT ksh93, GNU bash, zsh do
($EPOCHREALTIME, $PIPESTATUS, fallthrough in case, …)
• UTF-8 support in the Emacs command line editing mode and
string functions
• Home/End/Delete keys work by default (in most terminals, Emacs mode)
• somewhat configurable, e.g. exclude the Vi command line editing
mode, or some of the extensions too
• consistent 32-bit arithmetics with defined wraparound even for
signed integers, independent of the host platform; mksh extension
for unsigned integer arithmetics and “base-1 integers” (taking the
ASCII code or Unicode codepoint of a character)
• unlimited array subscripts (well, 32-bit really), plus a set of
shell functions that emulate associative and multi-dimensional
arrays on top of it, until the shell itself provides them
• some more builtins, like sleep (with microseconds), rename (just
the Unix rename(2) syscall), cat (with *no* options, no cat -v here)
• completely rewritten read builtin: can read into arrays by IFS
wordsplitting or by splitting on octet or multibyte (UTF-8) character
boundary; read with timeout; read exactly or up to N bytes; etc.
• large corpus of examples, like several things written in pure mksh
like the associative/multi-dimensional array kit, base64 (NUL safe),
several simpler hashes like Jenkins’ one-at-a-time, arc4random (by
reading from /dev/urandom); an LDIF parser (calling ldapsearch, rest
is pure mksh, goes into associative arrays from above), etc:
git clone https://evolvis.org/anonscm/git/shellsnippets/shellsnippets.git
• I consider *not* supporting recent bloat from ksh93/bash/zsh, like
floating point numbers, gettext, etc. a feature myself ;-)
• upcoming: efficient replacement for foo() { echo foo; }; x=$(foo)
mksh is OSI Certified Open Source Software under the MirOS Licence,
which is similar to BSD/MIT/X11 (plus strlcpy() for those who need
it, under the ISC licence).
Thanks for your consideration,
//mirabilos
--
16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Re: $ unset KSH_VERSION quits login shell
Dixi quod… I’ll change this to not abort for interactive shells then. Actually, I cannot reproduce that it causes an interactive shell to exit, neither like this… tg@blau:~ $ mksh -ic 'unset KSH_VERSION; echo $?,foo'; echo $? mksh: read-only: KSH_VERSION 1,foo 0 tg@blau:~ $ mksh -lc 'unset KSH_VERSION; echo $?,foo'; echo $? Agent pid 30022 mksh: read-only: KSH_VERSION 1,foo 0 … nor by typing it. Are you on NetBSD and is this maybe related to the SIGINT issue? bye, //mirabilos -- Hi, does anyone sell openbsd stickers by themselves and not packaged with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: $ unset KSH_VERSION quits login shell
Steffen Daode Nurpmeso dixit: |Please, if you patch mksh, append a space and a “vendor string” |to KSH_VERSION, like PLD: It's really only private (but it's git(1), i'll adjust the patch). Sure but as you can see it helps not confusing your version with upstream unpatched versions. Thanks, //mirabilos -- ch you introduced a merge commit│mika % g rebase -i HEAD^^ mika sorry, no idea and rebasing just fscked │mika Segmentation ch should have cloned into a clean repo │ fault (core dumped) ch if I rebase that now, it's really ugh │mika:#grml wuahh
Re: why not use signed ints in c?
oneofthem dixit: Wow, thanks. I didn't expect such an in depth response. You’re welcome ☺ I hope that this response will show up on search engines and help other coders, too, that’s why it was a tad lengthy. I think it can be extended even, e.g. with actual examples plus citations of the ISO C rules in question… this was meant as an intro/oversight/reasoning only. Maybe someone will follow up in the future ☺ I’m sure there are language gurus around somewhere. Or maybe someone else will just be happy to have discovered this topic and be angered at GCC just the same ;-) bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Re: why not use signed ints in c?
oneofthem dixit:
If you shouldn't use signed ints, then how do store negative numbers?
Basically, if you have something negative, you store it
either in a signed int, or in a typedef union {
mksh_ari_t i;
mksh_uari_t u;
} mksh_ari_u;
(where ari_t and uari_t are the signed and unsigned ints,
respectively), and do all arithmetics on it by using the
unsigned access, and do comparisons (other than == and !=)
and printing using the signed access.
This is legal in POSIX, and in C as long as the system uses
two’s complement. I was told that people arguing against this
have yet failed to show a workable C implementation on a system
not using two’s complement, so… fine.
bye,
//mirabilos
--
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh
Re: [ANN] mksh-R47 (must-have bugfix-only)
Jens Staal dixit: I have not looked at it yet - did the build-on-plan9 modifications Oh, sorry… they’re probably lost in my INBOX. Can you rebase them against R47 and send to me again (off-list to save traffic) for the next version? I have uploaded an archive that is intended to be extracted in / on Plan9 on two places: Thanks! The reason I ask is because when it in principle builds out-of-the box (although broken if not -DMKSH_NOPROSPECTOFWORK) it might be time to ask on 9fans for some help tracking down/fixing the blocking bug in the APE libraries (I could link to your previous email with the speculation on possible miscreants). Nice! If you have “connections”, sure, use them. bye, //mirabilos -- In Memoriam Uriel – Open Source Expressionist
Re: Fine Art in Silver
Steffen Daode Nurpmeso dixit: maybe this test would be worth adding to check.t. I think i do assume the correct behaviour. Indeed. A bit late, but I applied the testsuite part (not the dot.mkshrc part because I don’t think that should be default) with only very minor changes (basically, put it next to the other trap-* tests and rename it to something similar). Then I discovered my mksh on herc is too old and that your test broke between R41 and R41b. I tried to find the hunk that introduced that change and was a bit surprised at which one it was, and that it also breaks pressing ^C while the EXIT trap is defined… maybe that was one of your problems in the thread starting at http://thread.gmane.org/gmane.os.miros.mksh/91 too; if so please say so and I can finally put that thing out of my TOD^WINBOX. Finally, I decided on the most correct-ish fix I could do without breaking other things in the process. It’s not in mksh R47 but in CVS HEAD, so I’d love if you can give that a try – especially if it indeed closes your other issues too. Anyway, have a good time! Thanks, you too! By the way, if you have any other outstanding issues, please prod me again. Other than • EXIT trap and syntax errors • ^C exits shell (maybe the same problem?) • long job names I’ve not got any of yours on my radar atm… did I forget some? bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Re: mksh/Win32
Fabian Greffrath dixit: introduction that assumes nothing has been installed yet, There should be an msys.bat in your mingw directory. Run this with the I don’t even have one ☺ but … Get the lates installer from here to install MinGW/MSYS: … this helps, of course – thanks. All that wingw-w64 does in this regard is bundling the whole of MSYS into a single zip file. There are no other tools that come with it. It is, however, more convenient to point people to this zip file than leading them through the whole download and installations instructions for MinGW if they are just interested in the MSYS utilities. ;) Ah. Is that amd64-only or will it work with my win2k setup on “that laptop from 1999”? Regarding MSYS, I think development has halted when it was considered good enough to run the majority of ./configure scripts. There is a That’s enough for it goals, after all. reimplementation going on called MSYS2 which will be based on the current Cygwin development, but I don't know how far this is from I don’t think that’s really good because that dropped e.g. Win95 compatibility… but YMMV ☺ I mean, sure, as user I might want to install and use latest Cygwin, especially if I develop myself, but if I’m an upstream who wants to also provide Win32 binaries of his applications, using the old and more compatible versions fulfills my user story better. bye, //mirabilos (much too hot these days) -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
[ANN] jupp 25 released (and mksh R48b)
Hi everyone, today I’m also loudly announcing a jupp release, even though it’s “contrib” for MirBSD, just because it fixes several data corruption (on ^K/) and crash bugs. And if you hadn’t noticed already, mksh R48b fixes a display issue for multi-line prompts when resizing windows. Credits: Ypnose, Eike, Natureshadow. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh
Re: FYI: problem with wait(1)
Steffen Daode Nurpmeso dixit: ?1[steffen@sherwood]$ kill -STOP %1 Why STOP and not TSTP? (Not related, but curious.) ?0[steffen@sherwood]$ kill -CONT %1 The kernel does not communicate this to the shell, so it assumes the job is still stopped and thus out of job control. If you “bg”, it should™ work. bye, //mirabilos -- mirabilos│ untested Natureshadow │ tut natürlich Natureshadow │ was auch sonst ... mirabilos│ fijn ☺
Re: A draft for a multibyte and multi-codepoint C string interface
Steffen Daode Nurpmeso dixit: Hah. The fun starts on a non-UTF-8 tty: Well that much should be obvious: it’s not permitted to store raw octet filenames in a filesystem that requires Unicode canonical decomposed filenames. (I think this also violates some standard, somewhere.) And when mixing encodings in filenames, don’t go complain, either. By the way, mksh knows precisely two modes: Unicode/UTF-8 and “ASCII with an undefined upper half we just transparently pass through, working with SBCS”. This is by design, again (and, tbh, were it different, it still wouldn’t be able to “fix” this particular problem). Hey – i'm sorry that MirBSD can't be supported due to its 16-bit wide character! :) (At least until the sct_*() interface that works on the LC_CTYPE locale is optional OR i do have also .oO(eh?) And what’s got one to do with the other… but this has got nothing to do with mksh, so… bye, //mirabilos -- Hi, does anyone sell openbsd stickers by themselves and not packaged with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: mksh/win32 - bugs database
Earnie Boyd dixit: Try using something like 「print -r -- $PATH」 instead. Yes, that does the job of issuing the string without translation of characters by escape sequence. There are however a lot of scripts using echo. Mhm. One thing you can do is force the POSIX echo. Ah well – that’s mksh R39-based… *looks at old code* Your options are to set -o posix (which will change a lot more) or to use echo -E $PATH. bye, //mirabilos -- mirabilos│ untested Natureshadow │ tut natürlich Natureshadow │ was auch sonst ... mirabilos│ fijn ☺
Re: FYI: problem with wait(1)
Todd C. Miller dixit: I don't think there is a way for a process to be notified via SIGCHLD when a child process receives SIGCONT. So unless you are already in waitpid() with WCONTINUED set you won't see it. OK, thanks for confirming though. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: FYI: problem with wait(1)
Steffen Daode Nurpmeso dixit: I think i've misread what you said and also misunderstand; […] I do not understand your mail at all… sorry but I think we have a language or conceptual barrier here? bye, //mirabilos -- 20:49⎜«Natureshadow» Oops, jetzt hab ich mir doch glatt beim Trinken ⎜Mineralwasser ins Ohr gekippt… 21:04⎜«mirabilos» ist das siggbar? █ PS: سمَـَّوُوُحخ ̷̴خ ̷̴خ ̷̴خ امارتيخ ̷̴خ 21:05⎜«Natureshadow» mirabilos: was sollte dich davon abhalten…
Re: mksh/win32 - bugs database
Earnie Boyd dixit:
One can use either method as long as a method doesn't give unexpected
results to the end user. If you translate PATH to / then you need to
translate it back to \ before spawning a process because Windows OS
will not do the right thing with / in PATH.
Hrm. Well, maybe for mksh/Win32.
I would suggest training echo to not translate the escaped characters
of an environment variable.
“echo” just sees the string. By default, Korn Shell echo has
historically been “rich”, but I’d say we can make -E the default
on native Win32.
Michael, this is the patch (in R39) if you agree:
--- funcs.c~Thu Jul 30 19:11:11 2009
+++ funcs.c Wed Sep 11 13:09:52 2013
@@ -365,7 +365,7 @@ c_print(const char **wp)
char *xp;
if (wp[0][0] == 'e') { /* echo command */
- int nflags = flags;
+ int nflags = (flags = PO_NL);
/* A compromise between sysV and BSD echo commands:
* escape sequences are enabled by default, and
@@ -375,6 +375,7 @@ c_print(const char **wp)
* Different from sysV echo since options are recognised,
* different from BSD echo since escape sequences are enabled
* by default.
+* mksh/Win32 change: Disable escape sequences by default.
*/
wp += 1;
if (Flag(FPOSIX)) {
My interest in mksh-w32 is one of a replacement for MSYS. Getting rid
of the man-in-the-middle runtime would help speed up operations and
the less work the binary does spawning the better. At some point in
Right.
the distant future I'll take a look at the code and try to help out.
That’d be great!
Thanks,
//mirabilos
--
20:49⎜«Natureshadow» Oops, jetzt hab ich mir doch glatt beim Trinken
⎜Mineralwasser ins Ohr gekippt…
21:04⎜«mirabilos» ist das siggbar? █ PS: سمَـَّوُوُحخ ̷̴خ ̷̴خ ̷̴خ امارتيخ
̷̴خ
21:05⎜«Natureshadow» mirabilos: was sollte dich davon abhalten…
Cygwin/MSYS/… mksh
Uh guys, one thing in front: please stop Ccing me when mailing the list. I’ve read today that the -F option of ls(1) is _really_ slow in Cygwin (and related environments). I’m asking my packagers to patch dot.mkshrc for those environments if that is indeed true: -alias l='ls -F' +alias l='ls' Thanks, //mirabilos -- 20:49⎜«Natureshadow» Oops, jetzt hab ich mir doch glatt beim Trinken ⎜Mineralwasser ins Ohr gekippt… 21:04⎜«mirabilos» ist das siggbar? 21:05⎜«Natureshadow» mirabilos: was sollte dich davon abhalten…
Re: HISTTIMEFORMAT
Dave Jones dixit:
The response at the time was:
To be honest,
I'm actually opposed to persistent history files anyway
But obviously that is now possible...
They were always possible.
So the question is if timestamping somehow possible now or is it a feature I
can request again {ex. export HISTTIMEFORMAT=%F %T }?
No. Sorry.
bye,
//mirabilos
--
[ Natureshadow über meine Tendenz, seine IRL-Aussprüche zu siggen ]
(er) „Du bist besser als Twitter“
(ich) „Wieso? Weil ich das Wichtige herausfiltere?“
(er) „Und weil Du einfacher zu bedienen bist“
Re: Visual artifacts left in command line when text scrolled
Chris Sutcliffe dixit: Not sure if my mailer killed the escape sequences or not, but I don't see any '\r' in the example you provided. OK, then let’s send the stuff either uuencoded, or use the generic $'…' escaping form. to colour the return code red, if I understand correctly, I should do: (( e )) REPLY+=\001[31m\001$e| No. To colour something red, you send: ESC [ 3 1 m To “escape” something from being counted for the prompt width, you wrap it (on both sides) in a byte that tells mksh to ignore it. The byte you must define yourself, but it must be something not otherwise used in the prompt text. You do that by using it as first byte of the PS1 and ASCII CR as second byte of it. The manpage even has got examples on how to do that, as does dot.mkshrc (minus actually using colourising). So how about, you send me the prompt you want to have, possibly with colourising, as uuencode, and I’ll send it back? (You can also send it in GNU bash syntax…) bye, //mirabilos -- [ Natureshadow über meine Tendenz, seine IRL-Aussprüche zu siggen ] (er) „Du bist besser als Twitter“ (ich) „Wieso? Weil ich das Wichtige herausfiltere?“ (er) „Und weil Du einfacher zu bedienen bist“
Re: Visual artifacts left in command line when text scrolled
Chris Sutcliffe dixit: Thanks for the offer, below is my ps1 prompt based on the latest dot.mkshrc example where I'm trying to change the return code to red: OK, we can do this even without uu as it contains no magic chars. Use something like this: (( e )) REPLY+=$'\1\e[31m\1'$e|$'\1\e[0m\1' Maybe \e[1;31m for bold red… bye, //mirabilos -- [ Natureshadow über meine Tendenz, seine IRL-Aussprüche zu siggen ] (er) „Du bist besser als Twitter“ (ich) „Wieso? Weil ich das Wichtige herausfiltere?“ (er) „Und weil Du einfacher zu bedienen bist“
Re: Visual artifacts left in command line when text scrolled
Chris Sutcliffe dixit: Does it have something to do with the escape sequences being used inside Oh, ouch. (( e )) REPLY+=$'\''\1\e[31m\1'\''$e|$'\''\1\e[0m\1'\'' an inline function? It’s not a function, it’s a single-quoted string… at that time, anyway. Sorry about that. bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 18:35⎜asarch Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: Cygwin/MSYS/ mksh
Chris Sutcliffe dixit: I don't find it that slow, but if there is enough complaints about it, I Hmm. I can measure that a bit on my win2k installation (which is slow enough, hardware-wise, to be able to get representative data, even if most people would run faster systems). I’ll get back to you. bye, //mirabilos -- [00:02] Vutral gecko: benutzt du emacs ? [00:03] gecko nö [00:03] gecko nur n normalen mac [00:04] Vutral argl [00:04] Vutral ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: Sometimes the command line doesn't get keys right after job control events
Steffen Daode Nurpmeso dixit: i reproducibly fail to reproduce it, but regulary, once in a while Yeah, I get it occasionally too and cannot reproduce it – it’s been like that for years. Last time I had it when I was mplayering a radio stream and pkill’d it, but that is not reproducible right now, either. Sorry about that. But if you find it I’ll be glad ;-) For now… I also just press ^U and Enter when I’m hit by it (^U to get rid of whatever I already typed). I suspect some race condition, maybe when the to-be-killed program is multithreaded (or -processed) and one of its children dies later than when the command line is displayed, and the command line init code for the _next_ line will fix it up, and the child had “restored” the original tty state after edit.c already changed it… maybe someone could try to cobble together a test program for this theory. I’ve got the mother of all headaches today. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Re: Trouble in the variable expansion
Seb dixit:
It seems there is a problem in the way the R48b deals with the
spaces in the variables. Below is a piece of code showing the strange
Thanks for bringing this to my attention. Indeed, there appears to be
field splitting not done correctly, but at least it’s not m̲y̲ fault ☺
tg@frozenfish:~ $ pdksh -c 'x=X 1; echo shift ${x#X}'
shift 1
(That on Debian etch.)
Looking further¹:
tg@blau:~ $ x=X 1; dumpargs shift ${x#X}
args(3) 0:/usr/local/bin/dumpargs 1:shift 2: 3:1
tg@blau:~ $ x=X 1 2; dumpargs shift ${x#X}
args(4) 0:/usr/local/bin/dumpargs 1:shift 2: 3:1 4:2
So, apparently, the leading space creates an empty field.
Meh. On the other hand…
tg@blau:~ $ mksh /usr/src/contrib/code/Snippets/ifs.sh
# tests 6856 passed 6856 failed 0
The script – now http://www.research.att.com/~astopen/public/ifs.sh
as everything ~gsf/ seems to have been moved – hasn’t changed either,
which means you found something not covered by any existing tests.
I’ll look at this.
bye,
//mirabilos
① https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/dumpargs?rev=HEAD
--
„Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit
der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal
nicht…“ -- Natureshadow, per SMS
„Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x
Re: Working around f... GNU inetutils (1.9.1) behaviour
Steffen Daode Nurpmeso dixit: + cb.c_iflag = ~(ISTRIP); OK, applied. Thanks. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x
Re: mksh and multi-line editing
Stefan Heine dixit: on pdksh, I get an output showing one multi-line entry: [...] 16 echo foo bar That is not pdksh. tg@blau:/tmp/p/pdksh-5.2.14 $ PS1='x ' pdksh x echo a b a b x set -o emacs x history 1 echo a 2 b 3 set -o emacs Another thing, multi-line editing is not doable portably without involving some beast like libtermcap or terminfo because you cannot portably go “one line up”. Although a multi-line command line input editing mode is on even my own wishlist for years I believe we will not do that. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: More on history
Guido Berhoerster dixit: Hmm, I've done a bit more testing, sometimes it works, sometimes it does not Right, it’s not reliable. All I can tell you is that they synchronise with $HISTFILE upon pressing Enter (which implies that order may be important). use the same $HISTFILE but one seems to have gone ahead of the other and they do not get back in sync: Line numbers are out of sync anyway. Honestly, from looking at the source, I’d rather rip out the entire source code and remove persistent history feature. It cannot ever have worked, and I was only able to plug the worst things. I cannot design something that would work properly either (unless using a separate database server to store the history lines – and even then… line numbers are per shell, even though they do appear in the history file… I don’t get the reason behind that myself, either). I’ve done what I could to fix persistent history, and then some, but, tbh, you’re in unsupported territory there. I’ll not remove it, since it “mostly” works (but once the amount of lines in $HISTFILE reaches $HISTSIZE you better increase the latter or start praying or only ever run one interactive mksh instance), but that’s it. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: mksh question: clear screen on Ctrl+L
Benny Siegert dixit: I have a small question about mksh. In bash on GNU/Linux, a feature Or in GNU bash on MirBSD… that I really like is that Ctrl+L clears the screen. I am not saying that this should be the default behaviour on mksh as well but: is there any way that you can get this in mksh? Esc+^L works, or you can: echo bind '^L=clear-screen' ~/.mkshrc In inputrc maybe? No, inputrc is for GNU libreadline. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x
Re: Bug#732509: mksh: missing octal support in arithmetic expressions
Vincent Lefevre dixit:
I hate this feature because of the ambiguity with decimal, but
Indeed. It does break traditional Korn shell scripts; I believe
this to be the second-largest mistake in recent POSIX/shell.
The ambiguity happens often enough when dealing with zero-padded
dates (e.g. in dd.MM. or -MM-dd).
I had this in mksh, but the sheer amount of changes needed to
previously unsuspecting scripts that predate this support in
POSIX led me to revert this mistake.
mksh intends to behave like ksh93.
No. mksh only takes ATT ksh93 behaviour as primary rule of
thumb. In fact, you will find that ksh93 behaves unlike all
other modern shells in many ways, such as scoping.
I’m hacking *on* mksh so that I can write my programs *in*
mksh, which means mksh’s focus is that of a programming
language of its own that also happens to be largely POSIX
sh compatible and leaning on ATT ksh, but also GNU bash
and zsh.
So, it should support octal in arithmetic expressions.
If you need features I believe ultimal failures in POSIX¹,
or other legacy behaviour, you can use the lksh binary.
① Octal in arithmetics, and using the host C “long” type for them.
On the other hand, neither lksh (since it’s intended for
legacy scripts that have not yet been ported to run with
mksh) nor mksh enable support for octal handling ootb…
see the excerpt from the manpage:
| the test built-in command. Prefixing numbers with a sole digit zero ('0')
| leads to the shell interpreting it as base-8 integer in posix mode only;
| historically, (pd)ksh has never done so either anyway, and it's unsafe to
| do that, but POSIX demands it nowadays. As a special mksh extension,
I’ll place the word “octal” in there so a manpage search finds
it more easily, in the next version.
tg@freewrt:~ $ mksh -c 'echo $((010))'
10
tg@freewrt:~ $ lksh -c 'echo $((010))'
10
tg@freewrt:~ $ mksh -o posix -c 'echo $((010))'
8
tg@freewrt:~ $ lksh -o posix -c 'echo $((010))'
8
Shell: /bin/sh linked to /bin/dash
See /usr/share/doc/mksh/NEWS.Debian.gz for mksh (46-2), too.
Note that lksh in Debian, when called as sh, enables the POSIX
mode automatically:
tg@freewrt:~ $ ll /bin/sh
lrwxrwxrwx 1 root root 4 Aug 14 22:38 /bin/sh - lksh*
tg@freewrt:~ $ sh -c 'echo $((010))'
8
Hence, I believe this to be ⓐ sufficiently documented, and
ⓑ not relevant for cases where you need POSIXly broken be‐
haviour (#!/bin/sh), and close this bug in Debian, and ask
you to place all follow-up discussion, should the need for
it arise, on the upstream public mailing list. Thanks!
$ mksh -c '[ 10 -eq 010 ] echo OK'
OK
tg@freewrt:~ $ mksh -o posix -c '[ 10 -eq 010 ] echo OK'
OK
tg@freewrt:~ $ lksh -o posix -c '[ 10 -eq 010 ] echo OK'
OK
Sorry if I may be sounding rude, this is unintended,
but I caught the flu ☹
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Re: Bug#732509: mksh: missing octal support in arithmetic expressions
Vincent Lefevre dixit: Well, that's very confusing, because both ksh93 and mksh are ksh alternatives. This can break scripts with #!/bin/ksh. ksh93 can break scripts with #!/bin/ksh because interpreting leading-digit-zero numbers as octal is a *very* recent change, and is *known* to break existing scripts. Not the other way round. The mksh and mksh-static alternatives should be dropped. No. Note that lksh in Debian, when called as sh, enables the POSIX mode automatically: [...] But I assume that this is not the case of mksh. The mksh man page Since mksh 46-2, only “lksh” is supported as /bin/sh in Debian. This is also because of the printf(1) issue. So, the package description should be fixed. It currently says: This shell is Debian Policy 10.4 compliant and may be used as /bin/sh on Debian systems (if udev is installed, /bin/lksh should be used; otherwise, both /bin/mksh-static and /bin/mksh flavours also work), Right, this ^^ needs fixing. Will do in the next upload, thanks. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
ucc (was Re: [dev][announce] Optimizing C compiler c++ compiler/runtime)
Rob dixit: I've been working on a C compiler in my spare time and recently finished […] If anyone's interested. It's hosted here [1] and I'm all ears to critiques and feedback. 1: https://github.com/bobrippling/ucc-c-compiler Cool! I’ll probably play with it some time. By the way: just compiling mksh and running its testsuite has been proven to be a decent toolchain check – you won’t believe the amount of bugs I found in GCC (repeat offenders are -fwhole-program --combine and -flto) and various libcs (glibc/eglibc, µClibc, dietlibc, klibc, bionic) and other compilers (mostly PCC which I had viewn as way forward for MirBSD) along the way. So I suggest you add “build mksh then run its testsuite” to your compiler’s testsuite ☺ bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh
Re: mksh history file
Markus Teich dixit: I am using mksh for nearly a year now, but only recently I noticed some weird behaviour with the history file. When I have multiple pts open and enter a Command in one of them, it can't be found in the history of the others. It can, if you press Enter in the other shell. Also often the whole „local“ history of a pts gets lost when exiting that pts with Ctrl-D. In my .mkshrc I have: export HISTFILE=$HOME/.mksh_history export HISTSIZE=4200 If you have about 4198 entries, this behaviour will indeed exist. The only solutions here are to either raise HISTSIZE or truncate the history file to something smaller yourself (e.g. using the 「fc -l」 and 「print -s」 commands). This is parallel processing and unstable. I do not believe in persistent history, nor its current implementation, and have only retained it in mksh because it’s a really popular feature, but will continue to discourage using it (e.g. for privacy and data retention reasons, asides from code issues), even though I fixed the worst bugs. Is there a reason for using a binary format for the history instead of a simple textfile where each command is appended? Faster access, line numbers, and compatibility to earlier versions of mksh/mirbsdksh/oksh/pdksh. bye, //mirabilos PS: Can we bounce this to the mailing list? If you respond in positive I’ll do that. I believe this is of worth to most readers. -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift Ostdeutsche Eisenbahn durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x
Re: mksh @ Cygwin bug: backspace on two-byte characters
Philipp von Bassewitz dixit: vi mode is very fine for me. I hope it will be available for a long time even without UTF-8 support. A small hint in the man page would be helpful, like: OK, will do. (The headers were fine this time, thanks. It had only In-Reply-To but not References, which works nevertheless.) bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr]
Re: readonly on array broken?
Bert M�nnich dixit: $ arr=(foo bar) $ readonly arr $ arr=bla Is this a bug, or am I missing something? I've also checked `typeset -r arr[*]' which shows the same behaviour. Thanks for the report; this seems to be a bug in the code we inherited from pdksh indeed. Will fix. bye, //mirabilos -- Natureshadow Ach, mach doch was du willst, du hast doch eh immer Recht! mirabilos jupp ~/.etc/sig……… Natureshadow unfaßbar… Natureshadow Mit Eszett sogar, unfaßbar!
Re: executing ENV file
renkel dixit:
How do I get mksh to envoke the ENV file in called programs?
The initial program envoked gets it,
but programs it call do not
Eh…
… I’m not sure I understand what you want from me, but
${ENV:-~/.mkshrc} processing is done by interactive shells,
as documented in the manual page.
bye,
//mirabilos
--
Natureshadow Ach, mach doch was du willst, du hast doch eh immer Recht!
mirabilos jupp ~/.etc/sig………
Natureshadow unfaßbar…
Natureshadow Mit Eszett sogar, unfaßbar!
Re: editline support fuer mksh ?
dem...@arcor.de dixit: wie sieht es mit einer verwendung der bsd editline library in der mksh aus ? ich wuerde das sehr begruessen, editline ist doch den eingebauten funktionen ueberlegen. Genaues Gegenteil: die eingebauten Funktionen sind deutlich besser, fehlerfreier, und können UTF-8. Außerdem halten sie den Code kompakt und haben bisweilen (noch nicht überall wo sinnvoll auch verwendet) Zugriff auf die Interna. libedit benutzt stdio, was in mksh nicht verwendet wird, und wäre eine ungewollte externe Abhängigkeit. (Außerdem würde das etwas anderes, das ich vorhabe – die internen Funktionen so umschreiben, daß sie konsistent wide characters ver‐ wenden – verhindern.) es sollte natuerlich nur optional eingebaut werden, falls der user das wuenscht. Definitiv nicht! Ich habe großen Aufwand damit verbracht sicherzu‐ stellen, daß mksh sich auf jeder Plattform (so wie es eben geht) gleich verhält. was haelst du davon ? Sorry, aber: nichts. Gruß //mirabilos PS: Gern auch auf miros-mksh@mirbsd.org – wenn Du damit einver‐ standen bist, leite ich Deine Anfrage und diese Antwort auch dorthin weiter, damit alle was davon haben. -- mirabilos Owāte Jong… isch owāte disch gleisch… Natureshadow Ich kenn nur Oblate mirabilos Lernenz Platt Natureshadow Ich bin zu dick für Platt
Re: editline support fuer mksh ?
Jacko dixit: das war von mir auch nur ne vermutung, da sich die tcsh wesentlich geschmeidiger Hm, tut sie? Keine Ahnung… tcsh klingt nach FreeBSD… in der beziehung verhaelt und libedit doch aus ihr gewonnen wird. Huh? AUTHORS The editline library was written by Christos Zoulas. Luke Mewburn wrote this manual and implemented CC_REDISPLAY, CC_REFRESH_BEEP, EL_EDITMODE, and EL_RPROMPT. Jaromir Dolecek implemented the readline emulation. Hier nicht. libedit benutzt stdio, was in mksh nicht verwendet wird, und w??re huh ? haste dein eigenes stdio implementiert dafuer ? pdksh bereits, mit dem Kommentar, daß stdio auf zu vielen Systemen zu fragil sei (man denke, in welchen Situationen – Forks, Signale, usw. – die Shell das verwendet; außerdem fehlt fast überall %zu und/oder asprintf, wessen Äquivalent massenhaft verwendet wird in mksh; außerdem hätte das dann nicht das pool memory handling, das wir zum automatischen Freigeben am Blockende nutzen). Ich hab’s nur gefixt und erweitert (z.B. um UTF-8 Support, %zu, usw). ich find libedit faehigkeiten eigentlich ganz gut, ist nicht zle der zsh, Naja, zle der zsh ist in etwa Antithesis von mksh. Menschen, die sowas wollen, rate ich tatsächlich zur zsh (modulo Bugs). ok, meinethalben. ☑ done machs gut, mir gefaellt die mksh, leider ist ihr lineediting etwas spartanisch. Danke! Zum zweiten Satzteil: das ist sogar Absicht. Was ich noch fixen möchte ist, daß z.B. nach „echo $(foo) _“ wieder Dateien komplettiert werden, nach „(foo) _“ aber weiterhin Befehle, wie auch aktuell, also daß der Editor Einsicht in die Syntax kriegt. Aber prinzipiell soll mkshs Input Line Editing sich deterministisch verhalten, einen nicht überraschen, und kompakt sein. Ich kriege eine Shell auf Linux/i386-klibc in ca. 130 KiB statisch gelinkt. Das hat massig Vorteile. (Und nix in der Shell verwendet die FPU, was auch enorm hilft – und ein weiterer Grund gegen stdio ist… sobald Du mal was im Binary hast, das die FPU verwendet, müssen die Register auch immer gesichert werden, und so.) Gruß //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: editline support fuer mksh ?
dem...@arcor.de dixit:
The editline library was written by Christos Zoulas. Luke Mewburn wrote
^^^
dieser NetBSD entwickler ist
seit vielen jahren der maintainer der tcsh.
Ah okay, wußte ich nicht.
(man tcsh, siehe auch deren sourcen)
Ja… dafür müßte ich sie erstmal installieren… vermutlich sogar porten…
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
soso
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
Naja, sagt ein zsh-Entwickler. Wobei ich ksh93 auch… umständlich zu
bedienen finde, selbst nachdem man rausgefunden hat, daß man von Hand
„set -o emacs“ machen muß.
wasted half my life on my zsh setup. :-)
harhar, geht mir genau so, ich brauche aber den zsh stuff auch interaktiv.
OK. Dann ist mksh leider vermutlich interaktiv – außer für „mal eben“
oder so – nicht die richtige Shell. Ich will zwar Weltbeherrschung, aber
„use the right tool for the job“ hat Vorrang. (ash/dash komplett durch
mksh abzulösen fällt aber unter right tool…)
fuer skripte ist die mksh aber eine bessere wahl, da wesentlich genuegsamer.
ACK. Schneller, auch – insbesondere die statisch gelinkten Fassungen
(die, auf GNU-Systemen, nicht die glibc/eglibc benutzen).
per default ist ja meistens (leider) die grottige bash aktiviert.
viele leute wuerden es garnicht merken, wenn das die mksh waere.
Stimmt ;-) und das, worüber sich die meisten beschweren (und dann
auch nur das), ist, daß ^L nicht den ganzen Bildschirm leert (naja,
halt Esc+^L nehmen oder „bind ^L=clear-screen“ in die .mkshrc tun)…
wenn ich fuer shell server usw. zustaendig waere, wuerde ich erstmal
allen usern als default die mksh einstellen, wer mehr haben will muss
sich selbst drum kuemmern ...
BTDT ☻
mksh predigen und zsh trinken, so bin ich drauf. :PP
Naja, ich schreibe halt auch bisweilen Zeug, wo mksh aktuell die
falsche Wahl ist (auch wenn z.B. das Gros der Webseite in mksh
gehalten ist). Siehe oben, UTRTFTJ.
[ systemweites Äquivalent zur ~/.mkshrc ]
so muss der paranoide admin sich mit /etc/profile zum schikanieren
seiner user begnuegen und auf das einwirken auf interaktive nicht login
shells verzichten ... :-/
Tja, hat der paranoïde Admin halt Pech gehabt. Nein, das kommt immer
mal wieder auf, paßt aber nicht ins Konzept. Im Rückblick war ~/.mkshrc
für $ENV als Default sowieso falsch, aber damals habe ich, auch nach
Jahren von Anfragen, mich mal den Userwünschen gebeugt (und damit in
der Tat auch einige praktische Probleme gefixt).
Hoffe, Du bist jetzt nicht brüskiert oder so… manchmal passen halt
Userwünsche nicht ins „große Ganze“ – zumindest zum jeweiligen Zeit‐
punkt… andere Sachen hingegen mögen willkommen sein.
Gruß
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
Re: mksh on OS X and MacPorts
Ryan Schmidt dixit: Hello, I'm a developer with the MacPorts project. An mksh package was submitted to MacPorts today, and I just committed it. Thank you very much! So if you wanted to list that on your web site, you could do that. OK will do. You currently list Homebrew and Fink packages, and have a note Missing packaging: DarwinPorts/MacPorts (none at all). Note that you should not refer to the name DarwinPorts anymore; we changed our name to MacPorts in 2008. Okay, thanks. I’ll add/change this. I also wanted to report a bug I found. When building, it says: Hi from $MirOS: src/bin/mksh/Build.sh,v 1.655 2014/01/05 21:57:21 tg Exp $ on: $ hwprefs machine_type os_type os_class 2 | ./Build.sh: line 211: hwprefs: command not found It seems you're deliberately targeting Darwin OS (i.e. OS X) and in Actually, I was just trying to shove some information about the environment the shell was built in into the log, in case I get asked questions by packagers. I’ve gathered information from a friend who is a Macintosh user, and from what I could try out when he gave me ssh access to his laptop and his iPhone. that case running the hwprefs command, but no such command exists. If you want to get info about an OS X system, system_profiler, sw_vers or sysctl would be good commands to use. For example: Will add these (I’ll keep hwprefs for people building on older systems though). Thanks a lot. If there's other information you want to gather, let me know what information you want it to print and I'll see what I can do. Basically anything you can imagine either upstream or a porter or packager could want to know about the operating environment when debugging a build “post-mortem”, from the build log. Please Cc me on replies; I'm not subscribed to the list. Sure. http://news.gmane.org/gmane.os.miros.mksh also exists, feel free to use it. (The list is rather new; older mksh- related questions are at gmane.os.miros.general intermixed with generic MirBSD stuff. miros-mksh is forwarded to all miros-discuss subscribers.) bye, //mirabilos -- ah, that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour
Re: mksh on OS X and MacPorts
Ryan Schmidt dixit: Oh, I see now, yes, hwprefs does exist on older Mac OS X systems. But a survey of my systems says it only existed on Intel Macs running Mac OS X 10.4, 10.5, and 10.6 -- not later Intel systems, and not earlier PowerPC systems -- so it's not terribly portable. Right – I used what I got my hands on. version or CPU, so I'd use that instead. I don't know a command to In addition to, not instead. mksh is, by intent, portable to many many old OSes. The OS version is important, as is knowing what compiler was used, which you can get with $CC -v. (Depending on the version of OS X and Right, but that’s a separate part in the code. You might also care to know what version of sh is being used, since your build script depends on it. Yes, but the script does not know with which shell it was invoked. Could even be the previous /sw/bin/mksh from the last time it was built… outputting the shell used in a script and then continuing with it is *hard*. (Most of the shell detection code is invalid syntax in other shells, so my shell detection script uses 'exit' as soon as possible, per shell.) ah, that reminds me, thanks for the stellar entertainment that you and certain […] Must be a different person! I'm not on any Debian lists. No, that’s just one of my eMail signatures – it was behind sigdashes. Sorry if it confused you. bye, //mirabilos -- theftf Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian
Re: readonly on array broken?
Bert M�nnich dixit: Is this a bug, or am I missing something? I've also checked `typeset -r arr[*]' Fixed in CVS: MIRBSD KSH R49 2014/05/27 Thanks for the report, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Re: mksh on OS X and MacPorts
Ryan Schmidt dixit: which you can get with $CC -v. (Depending on the version of OS X and We have $CC -v in some other place already, but I’ve added all the others for now (in mksh CVS HEAD). Thanks for your contribution, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
[ANN] mksh R50, jupp 27
Hi *, we’ve got new versions. (This eMail is for those who asked for it.) https://www.mirbsd.org/permalinks/wlog-10_e20140629-tg.htm bye, //mirabilos PS: Also on my list, but need some serious hacking time more: mksh-in-Android (testing and submission), paxmirabilis, m4, mircksum, mircolumn, an as-of-now-unnamed fts/ftw replacement, also some hacking on kernel, cachebox, cachewolf, lynx, openssl, sendmail, xz, quilt, the website (mircodeunicode and bdfctool), … -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Re: [PATCH] Fix infinite loop in x_zots (edit.c)
Ivan Delalande dixit: In rare occasions, when invalid UTF-8 sequences are present in the command line buffer, the loop in x_zots() loops indefinitely because we have str xlp and x_col == xx_cols, so the condition for the loop Ouch. Thanks for noticing. will be true, but the actual code that increments the str pointer in the x_e_putc2 and x_e_putc3 functions is protected by the condition x_col xx_cols which is false, and so the pointer remains at the same value indefinitely. OK, will look at it. Thanks! This patch only fixes the infinite loop problem, not the fondamental problem of invalid UTF-8 sequences handling. This would really be nice to have something consistent there because the command line prompt really goes nuts when such sequences are present. Indeed. I’ve got (long-term) plans for rewriting the entire edit thing using wide character arrays (tbh, probably, the entire string handling in the shell, lexer, parser, etc) and killing the current Vi mode (possibly making a new one reusing Emacs mode functionality). But that’s still a few months or years into the future :( I think the current editing mode works well enough with UTF-8, which everyone “sane” uses, and will focus on the shell programming language first. Nevertheless, thank you a lot for caring! Known bugs should be fixed after all. bye, //mirabilos -- [00:02] Vutral gecko: benutzt du emacs ? [00:03] gecko nö [00:03] gecko nur n normalen mac [00:04] Vutral argl [00:04] Vutral ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: IFS=:; ${-+:foo:var} skips the first empty element
michael dixit:
So far so good. Seems on par with dash's quickness and far more capable. I
Right. More robust (and less buggy), too.
just wish I could get to the next line with CTRL-V CTRL-J. It's a stupid
There is no “next line” in mksh, at least not interactively.
But with ^Xe, you can spawn an editor on the current input line,
and writing and sending multiline input there should™ work.
(Disclaimer: only somewhat tested, amounting to what $PS2 does.)
habit I picked up rather than using a proper editor. Guess it's time to
break that habit, anyway. I do particularly like the dex editor, though.
You won’t win me over, what with jupp and all that ;-)
(And if there’s no jupp, I just use ed.)
This also works in GNU bash and ATT ksh93.
I know, but it's where it doesn't work that bugs me.
Sure. It’s just that ATT ksh93 is the model for most of mksh’s
behaviour, and GNU bash is something to keep in the eye as it’s
what GNU users expect, which is why I mentioned it.
I've been experimenting with writing out a shell sourceable argument array
that I can call on from any shell. Here's one way I *think* I have managed
Oh *wow*.
I tend to keep my scripts mksh-specific (but portable across
systems) and the shell portable, not the scripts portable to
various shells… living without certain amenities, especially
arrays often, makes me crazy ;)
So far it caters to three shells' peculiarities, though I have no doubt that
list will grow as I discover them, and I don't have a ksh93 to work with. 2
Right. For example, avoid printf(1) on mksh, but use the print
builtin (on all Korn shells).
ksh93, for small test things, is available though shbot on
Freenode IRC. Example:
20:26⎜shbot k# echo ${.sh.version}
20:26⎜[[shbot]] Version AJM 93u+ 2012-08-01
The first line is me writing
/msg shbot k# echo ${.sh.version}
and the second line is shbot running
ksh93 -'EOF'
echo ${.sh.version}
EOF
in a VM, displaying its output.
Anyway, regarding mksh, I have only to check if the very first split char is
the split delimiter, and, if so, add another. It isn't difficult to do. The
If this is about the bug you reported, it’s unwise to do this
by a check on the shell, as the bug is likely to eventually
get fixed, making your code buggy ;-)
Thanks again, mirabilos.
You’re welcome.
bye,
//mirabilos
--
theftf Ich gebs zu, jupp ist cool
-- theftf zu Natureshadow beim Fixen von Debian
Re: Bum behaviour of hash(1)
Steffen Nurpmeso dixit: just stumbled over a makefile which does Fix that Makefile. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh
Re: On the Security of mksh
ban...@openmailbox.org dixit: Hello, I wanted to ask a few questions about the security of mksh. We are currently debating its use over GNU bash in our anonymity-centric distro Whonix, in a very security sensitive package. It appears the closest thing to That’s nice. Thank you for asking. I strongly believe that mksh is the correct choice for secure shell programming. Thanks for coming towards us actively, in a sane medium (eMail, and possibly IRC, are much nicer than a webforum). the OpenBSD implementation of ksh thats packaged in Debian. Actually, that package was removed some time ago and is now superseded by mksh. I am also the Debian maintainer of it. And even before that, the pdksh package in Debian was not OpenBSD ksh, but contained a few of its patches (but not the cleanup). 1. How close is mksh to OpenBSD's oksh code? Are they the same package? OpenBSD’s ksh was used as starting point, and I track commits there, see whether they still apply and improve things, and, if so, take them over. If not, I merely record the time of the last sync. We have all the security-related goodies of OpenBSD, plus lots of other bugfixes and functionality improvements. 2. Have you or the OpenBSD project performed a security audit of mksh? I have no idea about the OpenBSD project. They would prefer to not hear from either their upstreams or downstreams, anyway. I have been continuously checking mksh code and operation for years, but not with a focus on security-specific issues, but in a more general “bug” scope (which would include, but not limit to, security-specific bugs). mksh is shipped with Android. This prompted a security review by Google’s Geremy Condra, who was “impressed” with the code. As a result, I merely added _even_ more explicit checking code to malloc size calculations. You may want to contact Geremy (see the AOSP Gerrit interface for details) on whatever he has to share about mksh. As mksh was integrated into other projects, such as MidnightBSD, Beastiebox, etc. people were generally positively impressed by the quality of the code. I’ve not heard of anyone who had a bad impression from mksh, ever. 3. How do both ksh implementations compare from a code correctness point of view? OpenBSD ksh is pretty much frozen, and is barely more correct than the last pdksh release from 1999. In contrast, mksh is *much* more POSIX-compatible, although, to achieve the best POSIX compliance you can, I suggest compiling *two* versions of mksh: /bin/mksh which can be used as users’ login shell and has all modern functionality, and /bin/lksh which is built with CPPFLAGS=-DMKSH_BINSHPOSIX and the -l option to Build.sh (the Debian package already does this, plus a few more things so that one can use lksh as /bin/sh on an unmodified Debian system). Recently, a bug came to my attention that I was not able to fix right away. As the bug was caused by a feature extension, that feature was removed until such time as we can fix the bug. I’m trying very hard to make mksh the best shell there is, within the scope (e.g. no floating point like ksh93, and no fancy and programmable completioin like GNU bash and zsh, but also no useless bloat, and compact and secure code). I’m generally talking with developers of other shells (such as the dash and posh maintainers, and Jilles Tjoelker from FreeBSD who maintains their /bin/sh, and sometimes David Korn (ATT ksh) and Chet Ramey (GNU bash)) and users, as well as the Austin Group (POSIX standards committee). While we sometimes disagree, we usually agree to disagree, and work together (unlike OpenBSD, which has an extremely closed development group; it’s very rare that someone can collaborate with OpenBSD developers on something, although I did get the one or other thing across in both directions sometimes). 4. In general do you audit your base system and its utilities? As time permits, yes. Thanks to the work already done by OpenBSD, there is not as much to do as with others; for example, the secure string functions are used all over the place, and we build with -Wformat and -Werror globally. I am trying to confirm the facts I've researched and posted in this discussion thread. https://www.whonix.org/forum/index.php/topic,444.msg3598.html#msg3598 MirBSD backdates to the 29th of August, 2002 ;-) means about a dozen years, not just a decade. I was an OpenBSD user, and before that, created a GNU/Linux distribution. mksh indeed supports a lot of GNU bash extensions which OpenBSD ksh doesn’t. Most are shared by ATT ksh93. I’m willing to help answer migration questions, either here or in the #!/bin/mksh IRC channel on freenode (yes, that’s really the channel’s name), including the differences between “full” mksh and “legacy” mode (for better POSIX compliance). oksh is not a drastically improved version. The code was cleaned up, including removal of portability code, but only a handful of bugs were fixed, and two or three new introduced. (Actually, oksh is
Re: Bug#760857: mksh shoould not export $RANDOM
Lorenzo Beretta dixit: The $RANDOM variable should not be exported: it's useless, and it may fool scripts that try to detect if the shell provides it. This is an upstream decision, please continue this either on the mailing list (Cc’d) or (if you really must) the Launchpad tracker. Actually, this is not useless: it’s imported into subshells, and mksh reads the environment at startup and lets it contribute to entropy there. The absence of proper arc4random() in most operating systems is really a PITA. We might throw it away (and just use arc4random() if there, and… whatever… if not), for the sake of simplicity. But then, lesser platforms (such as GNU/Linux) would have worse entropy in $RANDOM values. That being said, there is a Pure mksh™ implementation of arc4random() around… only downside is, it reads a lot of bytes from /dev/urandom, which kills Linux’ inferiour kernel RNG as well… I wish we had access to AT_RANDOM, but glibc uses all of it for its own purposes instead of setting up an SRNG¹… Anyway, I do not discuss upstream things like this in the Debian bugtracker, as this is most definitely not a bug in the package. bye, //mirabilos ① stretching RNG -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
[ksh93, mksh] How to un-nameref an identifier?
Hi David,
I’m having a slight problem (shbot runs ksh93 when asked “k#”):
19:06⎜mirabilos:#ksh k# nameref x=y; y=z; echo $x,$y; unset x; echo $x,$y
19:06⎜«shbot:#ksh» mirabilos: z,z
19:06⎜«shbot:#ksh» mirabilos: ,
19:06⎜mirabilos:#ksh k# nameref x=y; y=z; echo $x,$y; nameref x=; echo $x,$y
19:06⎜«shbot:#ksh» mirabilos: z,z
19:06⎜«shbot:#ksh» mirabilos: ksh: typeset: : invalid variable name
19:06⎜mirabilos:#ksh ok, ksh93 behaves the same… how does one “un-nameref” an
identifier?
This is mksh:
19:06⎜mirabilos:#ksh m# nameref x=y; y=z; echo $x,$y; nameref x=; echo $x,$y
19:06⎜«shbot:#ksh» mirabilos: z,z
19:06⎜«shbot:#ksh» mirabilos: mksh: x=: empty nameref target
19:07⎜mirabilos:#ksh pre-R50 mksh showed ',z' on the second line
For reference, the versions installed on shbot right now are:
19:17⎜mirabilos:#ksh k# echo ${.sh.version}
19:17⎜«shbot:#ksh» mirabilos: Version AJM 93u+ 2012-08-01
19:17⎜mirabilos:#ksh m# echo $KSH_VERSION
19:17⎜«shbot:#ksh» mirabilos: @(#)MIRBSD KSH R50 2014/07/28
Basically, I need something so that $x is no longer a nameref;
changing it to another target is of course possible, or leaving
a function in which it was a local variable, but what about the
main program in which I also want to occasionally use namerefs,
e.g. in sourced libraries?
I cannot let it refer to itself in either shell, either:
19:15⎜mirabilos:#ksh k# nameref x=y; y=z; echo $x,$y; nameref x=x; echo $x,$y
19:15⎜«shbot:#ksh» mirabilos: z,z
19:15⎜«shbot:#ksh» mirabilos: ksh: typeset: x: invalid self reference
mksh has: mksh: x: expression recurses on parameter
Right now, I believe using 'nameref x=' to un-nameref it
is the way to go, and would restore that for mksh, but since
it’s your feature, I thought I’d rather ask you first.
(You don’t sit in IRC on Freenode, do you?)
Thanks in advance,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: [ksh93, mksh] How to un-nameref an identifier?
Dixi quod… Hi David, Nevermind… 19:22⎜mirabilos:#ksh 550 5.1.1 d...@research.att.com: Recipient address rejected: User unknown in local ⎜recipient table 19:23⎜«jilles:#ksh» mirabilos, yes, dgk and gsf don't work there anymore Right now, I believe using 'nameref x=' to un-nameref it Nevermind this either… 19:25⎜«jilles:#ksh» un-nameref - try unset -n ? 19:25⎜mirabilos:#ksh ah, there's an unset -n? 19:25⎜mirabilos:#ksh k# nameref x=y; y=z; echo $x,$y; unset -n x; echo $x,$y 19:25⎜«shbot:#ksh» mirabilos: z,z 19:25⎜«shbot:#ksh» mirabilos: ,z I’m obviously not using ksh93, normally, so I was unaware. R50c coming up… bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Re: Bug#760857: mksh shoould not export $RANDOM
tl;dr: We probably should simplify the code (no promises about $RANDOM other than its value area) and not export $RANDOM any more, and only use arc4random-related functions where really convenient, “lesser” OSes are SOL. We move the task to get better random numbers on the script writers (and provide a sample implementation already), except on MirBSD, where it is convenient ☺ (but also probably only useful to replace dice rolls to decide on what to have for lunch that day). Lorenzo dixit: I was wondering if there would be any trouble replacing the lcg with a generator whose state is __made__ of n1 words - something like, off the top of my head, xor128, JKISS, you name it. Something I really want is a sponge construct, like Keccak, but one where you can constantly write to and read from. Since this is out of the scope of mksh, I’m somewhat tempted to remove the export and bring back the state we once had: • if arc4random() exists on the system, always use that • if arc4random() does not exist, just use an LCG with few extra seeding (stack address, etc.) or none at all (since the OSes without it likely also don’t have ASLR and so) This has several downsides: • we used to have set ±o arc4random ‣ one variant: constant, to see which one is in use ⇒ led to the LCG codepath being untested/buggy ‣ other variant: can enable/disable arc4random ⇒ code bloat, not much benefit • if using arc4random(), we use arc4random_addrandom() to feed assignments to $RANDOM back, but OpenBSD removed the interface… • we used to ship one, which wrote to /dev/urandom to feed back to the kernel, but the Gentoo Linux people didn’t like that • using arc4random() on systems where it’s not in libc will make it the packager’s choice, which we don’t like much But we can just bite the bullet here and say “we use arc4random if you have it, and otherwise you get something that always produces the same output sequence for the same assignment to RANDOM, and it’s your fault”. This a̲l̲s̲o̲ has a downside, namely people expecting deterministic output again, if they program and test on a “lesser” OS (one without arc4random), and we just use arc4random_pushb_fast() macro on MirBSD for pushback, and if it doesn’t exist (OpenBSD, Linux – also sorta lesser OSes) there is no pushback… As for “better” LCG-ish things: nah, it’s either cryptographically sound (aRC4) or speed/convenience. I think we’d be best off with an mksh not promising anything about the quality of its $RANDOM, and using arc4random() only where it is really convenient (e.g. on OpenBSD and MirBSD, the libc malloc() uses it already anyway). We kinda don’t promise anything in the manpage already… and it would shrink the code. Btw, agreed, arc4random should be everywhere. Right. But I have a pure shell implementation for when people really want it… example use: https://www.teckids.org/gitweb/?p=verein.git;a=blob;f=util/projrand;h=80f3210cf77314c630086def1062958a528414ab;hb=HEAD (Watch that space. I also already have the idea to add the timing of the “Glücksfee” (person doing the lottery drawing by hitting Return occasionally) to the arcfour state…) I didn't know urandom in linux had these kind of problems, but It does… modern arc4random uses chacha20, which only requires 16/32 bytes for its keys. N̲O̲T̲ “modern” but “OpenBSD’s latest”. This is not “modern”, it just follows a worrisome trend – not only is DJB’s code basically illegible (coding style) and incomprehensible to non-mathematicians, but also unlicenced software and thus violating http://www.openbsd.org/policy.html (especially the last two paragraphs), as it both is not ultimately clear whether DJB’s code is really in PD in the USA, and it most certainly is not in PD in most other countries. (DJB could fix that easily – others do – but refuses to even acknowledge the problem we non-US-Americans have. But then, his track record wrt. software licencing is pretty… dirty.) Anyway, I do not discuss upstream things like this in the Debian bugtracker, as this is most definitely not a bug in the package. You're totally right, sending emails is too easy - sorry :) Thanks for agreeing, and sorry for taking a bit to respond. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
Re: [ksh93, mksh] How to un-nameref an identifier?
Dixi quod… Right now, I believe using 'nameref x=' to un-nameref it Nevermind this either… R50c coming up… … or this. 20:21⎜mirabilos:#ksh m# nameref x=y; y=z; echo $x,$y; typeset +n x; echo $x,$y 20:21⎜«shbot:#ksh» mirabilos: z,z 20:21⎜«shbot:#ksh» mirabilos: y,z Thanks to ormaaj for reminding me… so, no R50c coming up ☺ bye, //mirabilos -- Hi, does anyone sell openbsd stickers by themselves and not packaged with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
here documents with mksh on Android (was Re: [Bug 1366451] Re: mksh -v should display mksh's version number, plus the attached chunk of text, onscreen)
Jason Spiro dixit: By the way, do here-documents work okay on modern versions of Android? Or is there no place for mksh to write the required temporary files to make them work? There is still no place. If you set (not even needed to export, but exporting is better so subshells inherit it) $TMPDIR, it works. If you are root, it works (I think). The AOSP people sorta-promised me either to set $TMPDIR in the launcher, or to give me an API I can use to query a directory which is writable for the current user (home directory, most likely). I have not received either, yet. You may want to prod them. As I do not use an Android device myself, things are slow from my side. bye, //mirabilos -- Why don't you use JavaScript? I also don't like enabling JavaScript in Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Re: here documents with mksh on Android
Jason Spiro dixit: If I may ask: How do you test mksh on Android? I boot up a VM at work (where I have sufficient space), which runs just the recommended AOSP build environment. Inside that, I build it, then I run “emulator” over VNC. Slow as hell, especially the VNC part. Then I have my testing routine (adb shell, adb install (regression), local shell with vx.connectbot used to be Dev Tools’ terminal emulator). Once, I managed to get perl working and ran the mksh testsuite – hard… Have you ever tried android-x86? I have no hardware for that, personally. Also, I work directly on AOSP, which makes testing kinda hard… I've found that it performs much better than ordinary Android running inside the official Android emulator. Maybe, but even so, it’s not AOSP, and running a VM inside a VM is not going to be fun either… bye, //mirabilos -- theftf Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian
Re: here documents with mksh on Android (was Re: [Bug 1366451] Re: mksh -v should display mksh's version number, plus the attached chunk of text, onscreen)
enh dixit: probably related to https://code.google.com/p/android/issues/detail?id=66815. i think the Right, similar issue. hard part is what to set $TMPDIR to. Agreed. If I get a C API I can just call, I would put it into main.c in mksh (set TMPDIR to that value, unless we import it from the environment already). Otherwise, something should ensure that $TMPDIR is set whenever mksh is called. Since the shell can be called various ways (during boot, adb, from a local application), this is pretty complicated; I’d suggest adding code to bionic which I can call might be easier. the AOSP x86 emulator is pretty fast, as long as you have hardware that lets you use kvm. just don't forget to supply the flag so the emulator takes advantage of it! Hrm. I’ll have to see if linux-kvm works inside a linux-kvm VM. IIRC, this works with AMD CPUs. What is the “magic invocation” to build for that, instead of for emulator (which I used to be as close to upstream as possible)? bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: Bug#760857: mksh shoould not export $RANDOM
Lorenzo dixit: The author says it's stronger than RC4, so (even if it hasn't been significantly analyzed yet) it's more than good enough for mksh since $RANDOM I’m currently of the mind to just not put any crypto code into mksh, and just use the LCG unless the OS ships with a very convenient arc4random() function. KISS, and all. So, I’m most definitely n̲o̲t̲ looking for algorithms. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Spritz (was Re: Bug#760857: mksh shoould not export $RANDOM)
Dixi quod… So, I’m most definitely n̲o̲t̲ looking for algorithms. That being said, after having read http://crypto.2014.rump.cr.yp.to/3de41b60e32a494c8f0fc9c21c67063a.pdf and the first ten pages (up to beginning of chapter 4) of http://people.csail.mit.edu/rivest/pubs/RS14.pdf I’m impressed (the stop symbol especially) and could consider making this the basis of an aRC4 replacement. The documentation appears good enough for implementing it myself, and it may be possible even to implement it in constant-time which is important in crypto nowadays. Its 1732 bit state beats the about 1700 bit of aRC4, too ;) although that is due to the increase in registers. bye, //mirabilos -- dileks ch: good, you corrected yourself. ppl tend to tweet such news immediately, sth. like grml devs seem to be buyablech dileks: we _are_. if you throw enough money in our direction, things will happen mika everyone is buyable, it's just a matter of price mrud and now comes [mira] and uses this as a signature ;0 -- they asked for it…
Re: Spritz
Lorenzo dixit: On 09/20/2014 07:14 PM, Thorsten Glaser wrote: appears good enough for implementing it myself, and it may be possible even to implement it in constant-time which is important Hm, or maybe not. Also, the algorithm is extremely slow as is already, and since MirBSD caters to the low-end machines, like my 80486SLC-25 and my by now seven (I got another) SPARCstations… … but then, if Spritz is really that good, I could greatly simplify the arc4random design with its several separate pools and all that, which would remove some of the speed overhead. (For example, we generate 5½ bytes of entropy to read a 4-byte quantity, all the time, which reduces speed to about ⅔ anyway.) Its 1732 bit state beats the about 1700 bit of aRC4, too ;) although that is due to the increase in registers. And some of it is lost due to the CRUSH function, at least possibly, but I think it doesn’t affect use of it as an SRNG. Glad to hear it :) Right ☺ No promise as to when I get around looking at it more; there are massively more important things to do, and I’m spread enough as is. But I’ve cached the PDFs and the bib.txt locally. bye, //mirabilos -- theftf Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian
Re: Spritz
Lorenzo dixit: Wait, wait - 1. MirBSD? Of course. 2. what did you measure exactly? Nothing, I just saw the comparative measurements in the paper. Are you considering RS14 for /dev/random? Of course not. Just for both /dev/arandom and userspace arc4random(). Making a portable arc4random() No, I don’t do that because other operating systems don’t provide sensible enough kernel interfaces. The closest one is OpenBSD, but even theirs suck. based on RS14 should be more than good enough for the portable version of mksh, even in terms of speed - or did you stop using arc4random() for $RANDOM because of this slow machines? No, mksh’s $RANDOM does not need arc4random() and does not promise it – I just use it when it’s convenient. I don’t use it on most OSes because almost all OSes don’t provide good and easy to use kernel interfaces to gather entropy, and I’d rather not have several fall‐ back mechanisms. Ie slowing down rndget() by a factor X has an impact which is much smaller than X due to the shell having to parse over and over, not to mention that in real usage you'd actually be doing something other than generating random numbers... We need to separate several concerns here: • do we use arc4random() for mksh, or rather, when • what provides arc4random() • arc4random() on MirBSD may or may not be using Spritz, it currently uses aRC4 • arc4random() on OpenBSD used aRC4 and uses ChaCha20 now, but lacks an interface to push back entropy to the kernel • arc4random() is not native to any other OS, and all portable implementations suck, both in themselves and because of their underlying operating systems (e.g. Linux deprecating sysctl(), and their new proposed getentropy syscall (incompatible to OpenBSD’s new one) sucks) • what do we do in mksh if an OS absolutely cannot support arc4random() (e.g. lack of /dev/urandom and similar) The last point is actually why I’d say, we only use arc4random() if “it’s there anyway”, which is basically OpenBSD and MirBSD “period”. Everything else gets an LCG, and I’m seriously considering removing all overhead and just using dumb mode there (that can also easily be tested for). (And OpenBSD just doesn’t get the kernel feedback, period. They asked for them to not get it, even.) bye, //mirabilos -- 22:20⎜asarch The crazy that persists in his craziness becomes a master 22:21⎜asarch And the distance between the craziness and geniality is only measured by the success 18:35⎜asarch Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: Spritz
Lorenzo dixit: The real problem is that you can't count on getrandom() being there - eg it's too new for my machine running debian sid... why they removed the sysctl() without providing an alternative is beyond me instead. Also, it’s Linux-specific, and not suitable for mksh anyway since mksh is early userspace. Oh, btw - I can't find the link right now, but someone took the pain to look at (and compare) many broken versions of portable functions, including arc4random. Oh, too bad. Do share once you know it ;) It was just plain horrible. I can fully imagine. OK, thanks for all the feedback. I have a rough idea where I want to go to now, and will do this once I have some hacking time for mksh again. bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;)
Re: Spritz
Dixi quod… Its 1732 bit state beats the about 1700 bit of aRC4, too ;) although that is due to the increase in registers. And some of it is lost due to the CRUSH function, at least OK. I slept over it, and I think that a Spritz-based stretching RNG, to replace aRC4 in arc4random(), has a bit more than 1476 bit and no more than 1604 bit of entropy in its state, due to use of CRUSH. This could probably be improved by changing SHUFFLE to: ⒈ local tmp1 = DRIP() ⒉ local tmp2 = DRIP() ⒊ local tmp3 = DRIP() ⒋ WHIP(2*N + tmp1) ⒌ tmp2 += DRIP() ⒍ tmp3 += DRIP() ⒎ CRUSH() ⒏ WHIP(2*N + tmp2) ⒐ tmp3 += DRIP() ⒑ CRUSH() ⒒ WHIP(2*N + tmp3) ⒓ a = 0 This is similar to the arc4random modifications we have in MirBSD, which not only skips 12*256 bytes of output after reseeding but also a somewhat random amount, and skips randomly 1‥2 bytes for every call to arc4random() and 1‥4 bytes for every 256 output bytes in a call to arc4random_buf(), just to further randomise (just like multiple readers of one pool, such as the kernel /dev/arandom, improve the “pool size” for every reader separately). Since this is deterministic, it could probably be also used in Spritz as stream cipher and hash ☺ @Ronald, Jacob: where can I keep informed about the state of Spritz, e.g. review/cryptanalysis (just the human-readable results please, not the academic details)? I see it has potential to simplify our RNG setup, especially due to the sponge construction, the ability to mix reading and writing (which Keccak does not really provide), and the AbsorbStop() function (nice!). This way, I can get rid of the temporary 128-bit “round hash” to spool incoming data, and just feed data straight into Spritz. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
Re: Spritz
Ronald L. Rivest dixit: There is no spritz mailing list or the like (yet); I'll let you know if we create one. We plan to publish an updated paper on Spritz within the next couple of weeks on the IACR eprint site: http://eprint.iacr.org/ OK, thank you. Keep an eye for this. The algorithm will be the same, but the analysis and discussion should be improved, over the version that is now posted on my web site... Okay. What did you think about this: This could probably be improved by changing SHUFFLE to: ⒈ local tmp1 = DRIP() ⒉ local tmp2 = DRIP() ⒊ local tmp3 = DRIP() ⒋ WHIP(2*N + tmp1) ⒌ tmp2 += DRIP() ⒍ tmp3 += DRIP() ⒎ CRUSH() ⒏ WHIP(2*N + tmp2) ⒐ tmp3 += DRIP() ⒑ CRUSH() ⒒ WHIP(2*N + tmp3) ⒓ a = 0 I think (intuition, not science; I’ve written down the idea basically as soon as I had it) that it should reduce loss of entropy in the state, which would benefit use of Spritz as RNG, and not harm use of it as hash and stream cipher other than a slight speed reduction. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: Spritz
Ronald L. Rivest dixit: I'm not sure why your proposed variation should produce reduced loss of entropy? CRUSH always reduces by 128 bit, but by changing the amount of WHIP calls before a CRUSH, we shuffle things around a bit more. This matches the random skips we currently use in arc4random. In any case, I don't think loss of entropy is a problem. The key space will be much much smaller than the state space, Not if using this as RNG, postprocessing output from something with 8192 bit of internal state, and more-or-less continuously feeding input into it. In this case, the “key” is much larger than the state. bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;)
Re: alias in mksh und vim
Tassilo Philipp | dyncall.org dixit: Und es wird auch ne mksh gestartet von vim aus, mache ich von vim aus: :!ps aux | grep sh dann sehe ich mich auch richtig selber: /usr/local/bin/mksh -c ps aux | grep sh OK, da haben wir es: das ist keine interaktive Shell. Mach ein -i vor das -c, falls das in vim geht, dann sollte es klappen. Gruß gn8, //mirabilos -- [00:02] Vutral gecko: benutzt du emacs ? [00:03] gecko nö [00:03] gecko nur n normalen mac [00:04] Vutral argl [00:04] Vutral ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: mksh should not export $RANDOM
Dixi quod… tl;dr: We probably should simplify the code (no promises about $RANDOM other than its value area) and not export $RANDOM any more, and only use arc4random-related functions where really convenient, “lesser” OSes are SOL. We move Later extensions (associative arrays) will require random numbers, though. For maintenance reasons (not exporting it eases maintenance burden on scripts), I will remove export RANDOM in the next mksh release. I won’t touch the code related to $RANDOM for now, though. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
mksh R50d
My sincerest apologies to packagers/downstreams, but I have found a regression in mksh today which made it necessary to ship another release. I’m packaging it for several distros/OSes, I know the pain. We get two bugfixes: unset x; nameref x ⇒ segfault (NULL pointer deref), except with glibc(‽) https://bugs.launchpad.net/mksh/+bug/1378208 With hopes that no new important bugs are going to pop up now, //mirabilos -- Looking for a new default signature.
[Bug 1381965] Re: mksh R50d: parser fixes break common “set -u” workaround, take two
Preliminary fix (as posted) committed and uploaded to Debian.
Better fix committed, needs more testing.
** Changed in: mksh
Status: Confirmed = In Progress
** Changed in: mksh
Assignee: (unassigned) = Thorsten Glaser (mirabilos)
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1381965
Title:
mksh R50d: parser fixes break common “set -u” workaround, take two
Status in The MirBSD Korn Shell:
In Progress
Bug description:
tglase@tglase:~ $ cat x
list_parts() {
local regex=${2:-}
local args=x
if [ -n $regex ]; then
args=${args} -regex '$regex'
fi
printf '%s\n' $args
}
list_parts foo
tglase@tglase:~ $ bash x
x
tglase@tglase:~ $ env -i PATH=$PATH mksh x
typeset -i -U BASHPID
typeset -i COLUMNS
typeset EPOCHREALTIME
typeset -x HOME
typeset IFS
typeset -i -U KSHEGID
typeset -i -U KSHGID
typeset -i -U KSHUID
typeset -r KSH_VERSION
typeset -i LINES
typeset -i OPTIND
typeset -x PATH
typeset -i -U PGRP
set -A PIPESTATUS
typeset -i -r -U PIPESTATUS[0]
typeset -i -U PPID
typeset PS1
typeset PS2
typeset PS3
typeset PS4
typeset PWD
typeset -i -U RANDOM
typeset -i SECONDS
typeset -x SHELL
typeset -i TMOUT
typeset -i -U USER_ID
x
Breaks: php5 maintainer scripts
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1381965/+subscriptions
[Bug 1381993] Re: more fun with $*
Preliminary fix committed, plus some test coverage. This is a real
problem, raising priority.
Fix needs to be extended; CVS HEAD needs to be tested better.
** Changed in: mksh
Importance: Low = High
** Changed in: mksh
Status: New = In Progress
** Changed in: mksh
Assignee: (unassigned) = Thorsten Glaser (mirabilos)
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1381993
Title:
more fun with $*
Status in The MirBSD Korn Shell:
In Progress
Bug description:
From: Stephane Chazelas stephane.chaze...@gmail.com
BTW, it looks like there's a bug in mksh:
tglase@tglase:~ $ bash -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
abc$
tglase@tglase:~ $ ./dash -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b |
sed -n l
c$
tglase@tglase:~ $ ksh93 -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
c$
tglase@tglase:~ $ lksh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
\a\300a$
abc$
tglase@tglase:~ $ mksh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
\a\300a$
abc$
tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a
b | sed -n l
abc$
tglase@tglase:~ $ mksh -o sh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b
| sed -n l
a$
abc$
The dash versions I have access to give the expected output
(same as your ksh93).
bash and pdksh join the arguments with spaces. And there's
nothing in POSIX that allows them to do that.
But:
ksh93 has some other interesting bugs:
tglase@tglase:~ $ bash -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ ./dash -c 'IFS=*; a=abcd; printf %s\n $*
${a##$*}' sh '' c
*c
abcd
tglase@tglase:~ $ ksh93 -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
d
tglase@tglase:~ $ lksh -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ mksh -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=*; a=abcd; printf %s\n $*
${a##$*}' sh '' c
*c
abcd
tl;dr: Fix the first and keep the second as-is.
And they don't say how those arrays are to be cast to scalars
when not in list context since they don't specify arrays in the
first place.
The non-list contexts include
a=$*
${a#$*}
case x in
$a) ...;;
$a) ...
esac
${a#$*} # beware quotes also serve to cancel globs there
$(( $* ))
...
Interesting use for the asn subst.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1381993/+subscriptions
Re: alias in mksh und vim
Tassilo Philipp | dyncall.org dixit: So weit so gut - liege ich damit richtig, dass der Unterschied ist, dass pdksh *immer* ENV reinzieht, aber mksh nur im interaktiven Modus? Sorry für die späte Antwort – aber ich habe gerade Sourcen und Historiën gelesen und alles, und festgestellt, daß dem in der Tat so ist. Das ist ein Bugfix, denn $ENV sollte in der Tat nur bei interaktiven Shells gelesen werden, nicht z.B. beim Lauf von make(1). Und mksh(1) dokumentiert: -i Interactive shell. A shell that reads commands from standard input is interactive if this option is used or if both stan- dard input and standard error are attached to a tty(4). An in- Kurzum: nein, Aliase gehen da nicht, außer der Befehl, den Du in vim ausführst, ist z.B. „mksh -ic aliasname“. Mache ich in jupp auch so, jetzt wo ich drüber nachdenke… POSIX sagt dazu: The shell shall read its input in terms of lines from a file, from a terminal in the case of an interactive shell, or from a string in the case of [30]sh -c or [31]system(). The input lines can be of Also vermutlich korrekt, daß -c nie interaktiv impliziert. Und: ENV This variable, when and only when an interactive shell is invoked, shall be subjected to parameter expansion (see [66]Parameter Expansion) by the shell and the resulting value shall be used as a pathname of a file containing shell commands to execute in the current environment. The Also auch korrekt, daß $ENV nur bei interaktiven Shells gerufen wird. tl;dr: weder ein Bug in vim noch einer in mksh, wohl einer in pdksh. Sorry für die Umstände. Gruß //mirabilos -- “The final straw, to be honest, was probably my amazement at the volume of petty, peevish whingeing certain of your peers are prone to dish out on -devel, telling each other how to talk more like a pretty princess, as though they were performing some kind of public service.” (someone to me, privately)
Re: Extending PS1 to width of terminal
Gerard Lally dixit:
OK my last question: I am lost! I am trying the following:
PS1 =
1) line break
2) reverse video, right-aligned $SHELL, $TERM, and $TTY, line break
This will not work without “bracketing” the ANSI codes in some
special character (see the manpage for this, the character is the
first byte of $PS1 when its second byte is an ASCII CR).
3) $hostname, line break
4) job number, path (~ if $HOME, ~/org if a subdir of $HOME, full path
otherwise), line break
5) user name, prompt ($ if user, # if root)
This is what I have: a complete mess, but I am learning slowly. I have
grabbed snippets from various places, including some of yours.
[\e[1;36m!\e[0m]$(local d=${PWD:-?} p=~ [[ $p = ?(*/) ]] || d=${d/#$p/~} print
-nr -- [\e[\
This is missing a newline (or semicolon) behind “p=~”.
path (not ~/org, for example), and I am not able to get the SHELL and
TTY variables to print on the first line. I also get the following
error:
mksh: typeset: [[: is not an identifier
Let me try to fix that up for you (and optimise it a bit)…
PS1=$'\001\r\n\001\e[1;7m\001${|
typeset -R$COLUMNS REPLY=[$SHELL|$TERM|$(tty)]
}\001\e[0m\001'[${HOSTNAME:=$(hostname)}]
$'[\001\e[1;36m\001!\001\e[0m\001]$(
local d=${PWD:-?} p=~
[[ $p = ?(*/) ]] || d=${d/#$p/~}
print -r -- [\001\e[1;35m\001$d\001\e[0m\001]
if (( USER_ID )); then
print -nr -- [\001\e[1;36m\001$(id -un)\001\e[0m\001]\$
else
print -nr -- [\001\e[1;35m\001$(id -un)\001\e[0m\001]#
fi
) '
… urgh, that’s colourful.
Have a lot of fun,
//mirabilos
--
How can you ban language, words? How're words offensive? And why should I
have to tolerate YOUR interpretation? I'm the one using the word. ASK me how
I'm using it, don't TELL me. And if you don't like the way I'm using it, so
what? It's my right. It's my freedom of expression. Without that, we're
nothing but slaves.-- Johnny Rotten
Re: Extending PS1 to width of terminal
Gerard Lally dixit: haha! Yes but it gives me an instant visual cue concerning path, user, and host. Thank you again: that is service beyond the call of duty! Nah. PS1 stuff is tricky, *and* it’s different from GNU bash, so I officially offer a PS1 service ☺ especially to get converts. You’re welcome, //mirabilos -- This space for rent.
Re: mksh should not use ptrdiff_t
Steffen Nurpmeso dixit: 11709 XSI On XSI-conformant systems, the intptr_t and uintptr_t types are required; otherwise, See. XSI is rare. So if you go POSIX I don’t. POSIX is still not ubiquitous. Also, POSIX is an ever-changing standard. use ssize_t with mksh I use it because it’s there on all systems (except SunOS, but on which it is trivially defined), not because some standard may say it must be there. When porting software, you must ignore standards and go with whatever you have. bye, //mirabilos (not that I l̲i̲k̲e̲ POSIX anyway) -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
mksh on Slackware (was Re: CVS: herc.mirbsd.org: src)
Hi all! Thanks for this: Commit ID: 100548597A713CD6746 CVSROOT: /cvs Module name: src Changes by:t...@herc.mirbsd.org2014/12/08 12:20:42 UTC Modified files: bin/mksh : Build.sh Log message: port this to GNU bash 1.12.1 from http://www.qemu-advent-calendar.org/#day-1 The image has JOE 0.1.5, some sort of jupp¹-ish editor, which made me happy. But I’ve got another problem: I can’t run mksh’s testsuite, whose driver is written in Perl, which I don’t speak. root@slack:/root/mksh # perl -v This is perl, version 4.0 $RCSfile: perl.c,v $$Revision: 4.0.1.7 $$Date: 92/06/08 14:50:39 $ Patch level: 35 Copyright (c) 1989, 1990, 1991, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 4.0 source kit. Any help in porting mksh/check.pl² to t̲h̲a̲t̲? ☺ Thanks in advance, //mirabilos ① https://www.mirbsd.org/jupp.htm ② https://www.mirbsd.org/cvs.cgi/src/bin/mksh/check.pl?rev=HEAD -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: [widened-REPOST] problem with parsing of $() inside ...
Stephane Chazelas dixit: [that's an email I sent to Thorsten a few weeks ago, reposting here as I'm not sure it was delivered OK]. Yeah, sorry about that, I read it, and I planned to look at it (thanks for the reproducers), but I haven’t gotten around doing so due to lack of suitable hacking time ☹ bye, //mirabilos -- This space for rent.
Re: mksh on Slackware (was Re: CVS: herc.mirbsd.org: src)
enh dixit: [ mksh testsuite ] have you considered using sh instead? :-) Not pure sh, that’s nowhere near enough. Maybe mksh. But if the one just built has issues, that may mask it. If another, you’ve got hen/egg problems. Maybe C. But then, (cross-)building a C program to test another one just built *may* (or may not) be more susceptible to errors than using a completely separate tool. No, I’m not happy with the current testsuite driver, but it’s there, it’s reasonably portable, and does its job, after some prodding (and I still don’t speak Perl). (there's no perl on Android, which makes running the mksh tests impractical. one can *build* perl for Android, i'm led to believe, but I’ve successfully (modulo the things that just didn’t exist, or didn’t work with toolbox) run the testsuite on Android (on the emulator) once, with a native Bionic perl. Nowadays, I’d probably just get a Linux/ARM box (Debian poterbox would be superb, except I retired from Debian recently), build a native Perl against dietlibc or musl, statically, then copy that over to Android, as it only relies on the kernel, and this is enough for the testsuite. Another idea we will have to try out: check if the testsuite can be run on the build system (instead of the target), using ssh (or adb shell) to invoke the to-be-tested utility on the target. Con: we’d probably need to NFS-mount or rsync the directory tree. But maybe something the *WRT people are also interested in. (Or we could move file generation to the target as well. Needs more hacking work in the testsuite driver.) Anyway, this is still enough short-term. bye, //mirabilos -- “The final straw, to be honest, was probably my amazement at the volume of petty, peevish whingeing certain of your peers are prone to dish out on -devel, telling each other how to talk more like a pretty princess, as though they were performing some kind of public service.” (someone to me, privately)
Re: IFS=; set a b; [[ $* = $1$2 ]]
Stephane Chazelas dixit: (with yesterday's git head and R46) Hm, I changed some things wrt. unquoted $* to be more bash-like, but… apparently, there is still loads to do. Not that I'd expect anyone to use anything but [[ $* = ... ]]. Indeed. (R46 gave a a there.) Ah, that is probably the one. But, as I said, I got lots todo on my plate, and OpenSSL is currently more pressing than mksh (apparently, all those field splitting things are obscure enough nobody noticed them in the last decade), even though I really need to fix some things, push out an R51 and probably R50e with less changes, too. I’ll just pile anything field splitting-related on top of what you and others sent me before and what I found out myself, for now… maybe fixing some will fix the others… still nice to have more testcases. bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
shellology: file descriptor redirection
Hi Debian bug, for completeness: mksh behaves similar to dash here, both wrt. the “interesting” fd behaviour and the change fixing it. Hi mksh mailing list, you might want to have a look at the bugreport and what subsequently became known about fd redirection. Michael Biebl dixit: There I suggested to use ( do_everything ) /dev/null 2 /dev/null as a possible workaround. I don't particularly like using a subshell but I'm just posting it for completeness sake here. Unfortunately, this does *not* instruct mksh to close the copies of those saved file descriptors, whereas redirecting them explicitly using the (in this case misnamed) exec builtin does. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.rShell behaviour: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987#119 bash parent(13765): lrwx-- 0 - /dev/pts/1 bash parent(13765): l-wx-- 1 - /home/tglase/xout bash parent(13765): l-wx-- 2 - /home/tglase/xerr bash parent(13765): lr-x-- 255 - /home/tglase/xscript bash chldfn(13769): lr-x-- 0 - /dev/null bash chldfn(13769): l-wx-- 1 - /dev/null bash chldfn(13769): l-wx-- 2 - /dev/null mksh parent(13780): l-wx-- 1 - /home/tglase/xout mksh parent(13780): l-wx-- 2 - /home/tglase/xerr mksh parent(13780): lrwx-- 24 - /dev/tty mksh parent(13780): lr-x-- 25 - /home/tglase/xscript mksh parent(13780): lrwx-- 26 - /dev/pts/1 mksh chldfn(13784): l-wx-- 1 - /dev/null mksh chldfn(13784): l-wx-- 2 - /dev/null mksh chldfn(13784): lrwx-- 24 - /dev/tty mksh chldfn(13784): lr-x-- 25 - /home/tglase/xscript mksh chldfn(13784): l-wx-- 26 - /home/tglase/xout mksh chldfn(13784): l-wx-- 27 - /home/tglase/xerr mksh chldfn(13784): lr-x-- 28 - /dev/null dash parent(13791): lrwx-- 0 - /dev/pts/1 dash parent(13791): l-wx-- 1 - /home/tglase/xout dash parent(13791): lr-x-- 10 - /home/tglase/xscript dash parent(13791): l-wx-- 2 - /home/tglase/xerr dash chldfn(13795): lr-x-- 0 - /dev/null dash chldfn(13795): l-wx-- 1 - /dev/null dash chldfn(13795): l-wx-- 10 - /home/tglase/xout dash chldfn(13795): l-wx-- 11 - /home/tglase/xerr dash chldfn(13795): l-wx-- 2 - /dev/null The patch… -do_everything /dev/null 2 /dev/null +exec /dev/null 2 /dev/null +do_everything … also works with mksh.
[Bug 1429469] Re: Please merge mksh 50e-2 (main) from Debian experimental (main)
** Attachment added: Debian source package - dsc https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+attachment/4337510/+files/mksh_50e-2ubuntu1.dsc -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh in Ubuntu. Matching subscriptions: mkshlist-to-ubuntu-bugmail https://bugs.launchpad.net/bugs/1429469 Title: Please merge mksh 50e-2 (main) from Debian experimental (main) Status in mksh package in Ubuntu: New Bug description: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+subscriptions
[Bug 1429469] Re: Please merge mksh 50e-2 (main) from Debian experimental (main)
** Patch added: debdiff against version in vivid https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+attachment/4337514/+files/mksh_50e-2ubuntu1.debdiff -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh in Ubuntu. Matching subscriptions: mkshlist-to-ubuntu-bugmail https://bugs.launchpad.net/bugs/1429469 Title: Please merge mksh 50e-2 (main) from Debian experimental (main) Status in mksh package in Ubuntu: New Bug description: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+subscriptions
[Bug 1429469] Re: Please merge mksh 50e-2 (main) from Debian experimental (main)
** Attachment added: Debian source package - debian.tar.xz https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+attachment/4337509/+files/mksh_50e-2ubuntu1.debian.tar.xz -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh in Ubuntu. Matching subscriptions: mkshlist-to-ubuntu-bugmail https://bugs.launchpad.net/bugs/1429469 Title: Please merge mksh 50e-2 (main) from Debian experimental (main) Status in mksh package in Ubuntu: New Bug description: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+subscriptions
[Bug 1429469] Re: Please merge mksh 50e-2 (main) from Debian experimental (main)
Same procedure as last time: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1377295 Authorisation: I am upstream and de-facto-still maintainer of this in Debian (just no longer listed in the Maintainer line due to leaving the project formally) -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh in Ubuntu. Matching subscriptions: mkshlist-to-ubuntu-bugmail https://bugs.launchpad.net/bugs/1429469 Title: Please merge mksh 50e-2 (main) from Debian experimental (main) Status in mksh package in Ubuntu: New Bug description: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+subscriptions
[Bug 1429469] [NEW] Please merge mksh 50e-2 (main) from Debian experimental (main)
Public bug reported: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 ** Affects: mksh (Ubuntu) Importance: Undecided Status: New ** Description changed: Binary package hint: mksh, pdksh Hi! - Please merge the latest mksh version I will be uploading to Debian experimental shortly. - It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. + Please merge the latest mksh version I will be uploading to Debian + experimental shortly. It contains a new stable release plus today's + security fix. It lands in experimental only due to the current freeze in + Debian, but is otherwise suitable for a stable release. - I’ll attach a debdiff against Debian and one against the last Ubuntu - version. + I’ll attach a debdiff against the last Ubuntu version, and the source + package. Thanks! The new changelog entries are: + + mksh (50e-2ubuntu1) vivid; urgency=high + + * Merge from Debian (LP: #1429469), remaining changes: + - Omit dietlibc builds on Ubuntu, where it is not in main + - Maintainer change
[Bug 1429469] Re: Please merge mksh 50e-2 (main) from Debian experimental (main)
I've also uploaded the .dsc to my PPA and looked over the build logs, they look good. https://launchpad.net/~mirabilos/+archive/ubuntu/ppa/+sourcepub/4821376 /+listing-archive-extra -- You received this bug notification because you are a member of mksh Mailing List, which is subscribed to mksh in Ubuntu. Matching subscriptions: mkshlist-to-ubuntu-bugmail https://bugs.launchpad.net/bugs/1429469 Title: Please merge mksh 50e-2 (main) from Debian experimental (main) Status in mksh package in Ubuntu: New Bug description: Binary package hint: mksh, pdksh Hi! Please merge the latest mksh version I will be uploading to Debian experimental shortly. It contains a new stable release plus today's security fix. It lands in experimental only due to the current freeze in Debian, but is otherwise suitable for a stable release. I’ll attach a debdiff against the last Ubuntu version, and the source package. Thanks! The new changelog entries are: mksh (50e-2ubuntu1) vivid; urgency=high * Merge from Debian (LP: #1429469), remaining changes: - Omit dietlibc builds on Ubuntu, where it is not in main - Maintainer change for Ubuntu -- Thorsten Glaser t.gla...@tarent.de Sat, 07 Mar 2015 23:42:38 + mksh (50e-2) experimental; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 23:30:36 + mksh (50e-1) experimental; urgency=high * QA upload. * Remove timestamps from README.Debian; should make builds reproducible * Filter out some more junk from README.Debian * Update to the next release of the R50-stable branch: - [tg] Fix LP#1381965 and LP#1381993 (more field splitting) - [jilles] Update location of FreeBSD testsuite for test(1) - [Martin Natano] Remove dead NULL elements from Emacs keybindings - [tg, Stéphane Chazelas, Geoff Clare] Change several testcases for $*/$@ expansion with/without quotes to expected-fail, with even more to come ☹ - [tg] Fix miscalculating required memory for encoding the double-quoted parts of a here document or here string delimiter, leading to a buffer overflow; discovered by zacts from IRC - [RT] Rename a function conflicting with a MacRelix system header - [tg] Use size_t (and ssize_t) consistently, stop using ptrdiff_t; fixes some arithmetics and S/390 bugs - [tg] Remove old workarounds for Clang 3.2 scan-build - [tg] Remove all Clang/Coverity assertions, making room for new checks - [tg] Fix NSIG generation on Debian sid gcc-snapshot - [tg] Make a testcase not fail in a corner case - [tg] Fix issues detected by GCC’s new sanitisers: data type of a value to be shifted constantly must be unsigned (what not, in C…); shebang check array accesses are always unsigned char - [tg] Be even more explicit wrt. POSIX in the manpage - [tg] Fix shebang / file magic decoding - [tg] More int → bool conversion - [tg] Let Build.sh be run by GNU bash 1.12.1 (Slackware 1.01) - [Stéphane Chazelas, tg] Fix here string parsing issue - [tg] Point out more future changes in the manpage - [tg] Call setgid(2), setegid(2), setuid(2) before seteuid(2) - [tg] Fix spurious empty line after ENOENT “whence -v”, found by Ypnose - [tg] Optimise dot.mkshrc and modernise it a bit - [tg] Use MAXPATHLEN from sys/param.h for PATH_MAX fallback - [tg] Some code cleanup and warnings fixes - [tg] Add options -a argv0 and -c to exec - [jsg] Prevent use-after-free when hitting multiple errors unwinding - [tg] Fix use of $* and $@ in scalar context: within [[ … ]] and after case (spotted by Stéphane Chazelas) and in here documents (spotted by tg@); fix here document expansion - [tg] Unbreak when $@ shares double quotes with others - [tg] Fix set -x in PS4 expansion infinite loop * Update README, Description, copyright and build scripts * Upload to experimental due to the jessie pre-release freeze -- Thorsten Glaser t...@mirbsd.de Sun, 01 Mar 2015 16:38:11 + mksh (50d-4) unstable; urgency=medium * QA upload. * Backport upstream fix: - [tg] SECURITY: make unset HISTFILE actually work * Adjust shell version accordingly -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1429469/+subscriptions
[Bug 1381965] Re: mksh R50d: parser fixes break common “set -u” workaround, take two
mksh R50e is out
** Changed in: mksh
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1381965
Title:
mksh R50d: parser fixes break common “set -u” workaround, take two
Status in The MirBSD Korn Shell:
Fix Released
Bug description:
tglase@tglase:~ $ cat x
list_parts() {
local regex=${2:-}
local args=x
if [ -n $regex ]; then
args=${args} -regex '$regex'
fi
printf '%s\n' $args
}
list_parts foo
tglase@tglase:~ $ bash x
x
tglase@tglase:~ $ env -i PATH=$PATH mksh x
typeset -i -U BASHPID
typeset -i COLUMNS
typeset EPOCHREALTIME
typeset -x HOME
typeset IFS
typeset -i -U KSHEGID
typeset -i -U KSHGID
typeset -i -U KSHUID
typeset -r KSH_VERSION
typeset -i LINES
typeset -i OPTIND
typeset -x PATH
typeset -i -U PGRP
set -A PIPESTATUS
typeset -i -r -U PIPESTATUS[0]
typeset -i -U PPID
typeset PS1
typeset PS2
typeset PS3
typeset PS4
typeset PWD
typeset -i -U RANDOM
typeset -i SECONDS
typeset -x SHELL
typeset -i TMOUT
typeset -i -U USER_ID
x
Breaks: php5 maintainer scripts
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1381965/+subscriptions
[Bug 1381993] Re: more fun with $*
mksh R50e is out
** Changed in: mksh
Status: In Progress = Fix Released
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1381993
Title:
more fun with $*
Status in The MirBSD Korn Shell:
Fix Released
Bug description:
From: Stephane Chazelas stephane.chaze...@gmail.com
BTW, it looks like there's a bug in mksh:
tglase@tglase:~ $ bash -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
abc$
tglase@tglase:~ $ ./dash -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b |
sed -n l
c$
tglase@tglase:~ $ ksh93 -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
c$
tglase@tglase:~ $ lksh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
\a\300a$
abc$
tglase@tglase:~ $ mksh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b | sed
-n l
\a\300a$
abc$
tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a
b | sed -n l
abc$
tglase@tglase:~ $ mksh -o sh -c 'IFS=; x=abc; printf %s\n ${x#$*}' x a b
| sed -n l
a$
abc$
The dash versions I have access to give the expected output
(same as your ksh93).
bash and pdksh join the arguments with spaces. And there's
nothing in POSIX that allows them to do that.
But:
ksh93 has some other interesting bugs:
tglase@tglase:~ $ bash -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ ./dash -c 'IFS=*; a=abcd; printf %s\n $*
${a##$*}' sh '' c
*c
abcd
tglase@tglase:~ $ ksh93 -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
d
tglase@tglase:~ $ lksh -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ mksh -c 'IFS=*; a=abcd; printf %s\n $* ${a##$*}'
sh '' c
*c
abcd
tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=*; a=abcd; printf %s\n $*
${a##$*}' sh '' c
*c
abcd
tl;dr: Fix the first and keep the second as-is.
And they don't say how those arrays are to be cast to scalars
when not in list context since they don't specify arrays in the
first place.
The non-list contexts include
a=$*
${a#$*}
case x in
$a) ...;;
$a) ...
esac
${a#$*} # beware quotes also serve to cancel globs there
$(( $* ))
...
Interesting use for the asn subst.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1381993/+subscriptions
[ANN] mksh R50e
Hi everyone, between coughing and sneezing I pushed out an upgrade of the stable branch of mksh (plus a small new patch to fix an infinite recursion problem), as I called for testing, and nobody complained, what’s in CVS HEAD for a while. So, enjoy R50e (mandatory bugfix upgrade with only a few new things). Changes since R50d: https://www.mirbsd.org/mksh.htm#r50e Changes in HEAD not included: https://www.mirbsd.org/mksh.htm#clog If you’ve already been running a snapshot version inclu‐ ding the integer base change, you may want to keep using CVS HEAD; otherwise, upgrade to R50e. MirPorts, Debian experimental, and my own *.deb repo al‐ ready carry the new version, as does the OpenSuSE Build‐ service; the latter two have CVS HEAD, the other two use the release. I expect packagers to read this eMail for a prod to upgrade. bye, //mirabilos -- This space for rent.
Re: trap recursion until SIGSEGV (non-interactive)
Steffen Nurpmeso dixit: a different, even older message: use a recursion counter, how wacky that may be. Nah. It’s either too high (with the obvious effect) or, like PHP’s, way too low (1000 just doesn’t cut it in may legitimate cases). And even a too-low one can still segfault if the user plays with ulimit -s. It's just that i am with the one that got no answer in that it didn't feel right. Just forget about it. Yeah, sorry about it. enh dixit: VMs have to deal with the more general case of this problem so they can throw whatever stack overflow exception their language defines. Hm. Not that I ever implemented even a toy VM worth note, but I’d most definitely not use the host’s stack for the VM stack, rather allocate the latter on the host heap. work out where the main thread's stack should end from /proc/maps and Ah, but that assumes there i̲s̲ a /proc/maps in the first place. surprisingly brittle, non-portable, and hard to get right though, so i'm not recommending you bother. Right. I w̲a̲s̲ wondering a bit… about a stack underflow SIGSEGV being the only one I can’t really catch… but then I remembered sigaltstack(2). Still, once I caught the SIGSEGV, what is there I can do… I guess in this case I could (after maybe setting a flag) siglongjmp to the next “up” error handler… but for that, I’d have to know that the cause of the SIGSEGV was actually a stack underflow. Or, on some platforms, stack over(!)flow. I’ve got to admit that this part of Unix is something I’m still not familiar enough with. bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;)
Re: [PATCH] 'command -v' does not find reserved words
Martijn Dekker dixit: The one-line change in the patch below fixes it, to the best of my I think so too. Applied, plus manpage updated. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999
