Steffen Nurpmeso dixit:
> #include
> #include
> #include
> #include
> int main(void){
> char inb[16], oub[16], *inbp, *oubp;
> iconv_t id;
> size_t inl, oul;
>
> memcpy(inbp = inb, "a\303\244c", sizeof("a\303\244c"));
> inl = sizeof("a\303\244c") -1;
Not -1 otherwise
Joerg Schilling via austin-group-l at The Open Group dixit:
>OK, mksh pdksh and posh have te same origin.
>I don't know oksh, loksh
oksh is basically where mksh took off, an intermediate, pdksh without
its compatibility layer and with a small amount of bugfixes; loksh is
a GNU/Linux port of
Steffen Nurpmeso via austin-group-l at The Open Group dixit:
> |This is because m4.opengroup.org runs qmail, the arsehole under the MTAs,
> |which auto-converted the mail from quoted-printable to 8bit, sending it
> |as 8bit even to MTAs that don't offer 8BITMIME (I configured my sendmail
> |not
ven to MTAs that don't offer 8BITMIME (I configured my sendmail
not to do that as well, so I got the same truncated mail back :( other
than qmail, exim is known to break the MIME and SMTP standards like that).
Here's it from my sent-mail folder, reduced to ASCII:
>>From: Thorsten Glaser
>
Hi *,
I’ve got a report in IRC by a user who spotted a cross-shell difference.
In my opinion, the invocation…
sh -c 'ls() { echo meow; }; exec ls'
… is supposed to output "meow\n and return to the caller with a zero
errorlevel.
Some shells execve() the ls(1) binary instead.
In
fixed in R59c, hopefully without breaking anything more
** Changed in: mksh
Status: Triaged => 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
KPECT dixit:
>Are you still planning to to implement associative arrays in mksh? This
>feature has been long awaited since 2011, but so far there are no
Yes, long-term. I’d also wish to add multi-dimensional arrays and JSON
{,de}serialisation in the same go, to avoid touching that code twice,
Hi Martijn,
>>> We're at R56 now but nothing seems to have changed here. Status?
>>
>> It’s on the TODO.
>
> Here's another attempt at a patch. Note that this version checks for OFF(i) !=
> OF_CMDLINE to exclude immutable command line-only options (interactive, login,
> restricted, stdin).
I’ve
Martijn Dekker dixit:
> As of mksh-R59 there is a regression in glob pattern matching with '[['.
Thanks, fixed.
I’m too tired to release R59b tonight, so if you have got any other
bugs/regressions to go into it before I do so tomorrow or so… do tell.
You seem to have more weird-corner-case test
Salve Noctambule,
>I have a question about sleep builtin. I'm writing a script and at the
>end, I want it to simply wait for SIGINT (from user) or signals with
>kill builtin.
The normal way to terminate sleep is SIGALRM though, but SIGINT
will most likely also work (try it out).
>What is the
n8dandy dixit:
>Yesterday, I was extensively using traps with mksh and I noticed something
>unexpected.
>Let's consider the following example, from the book "Learning the Korn shell,
>2nd
Well, mksh isn’t AT ksh ☺
In general, the *first* edition of that book (orelly/unix/ksh/)
works better
] Correct documentation of vi mode @c
- [tg] Update to UCD 13.0.0
- [tg] Use nanoseconds in test -nt / -ot (LP#1855325)
* Work around debhelper issue #908845 (Niels Thykier)
* Update lintian overrides
-- Thorsten Glaser Fri, 27 Mar 2020 12:59:25 +0100
With my Debian Developer hat
** 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/1855167
Title:
Comparatively poor
** Changed in: mksh
Status: Confirmed => 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/1855325
Title:
test -nt and -ot
** 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/1857826
Title:
mksh isglobal ASAN
** 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/1857195
Title:
here string
** 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/1857828
Title:
mksh expand ASAN
** 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/1857702
Title:
" +=" operator
** 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/1779179
Title:
nōn-ASCII heredoc
Public bug reported:
A roll-up of a couple of bugfixes (this is almost identical to the
upcoming new upstream release), but, more importantly, introduction of
autopkgtests. I’d prefer these fixes to be in focal due to LTS, and
especially as mksh 58 will be very close to this code, have the chance
OK, turns out that this was indeed a bug (but the presence of DOHEREDOC
probably predates the existence of DOSCALAR so understandable). I hope
this doesn’t introduce any regressions. Testcase also committed.
** Changed in: mksh
Status: Triaged => Fix Committed
--
You received this bug
severity 952970 wishlist
tags 952970 upstream
forwarded 952970 miros-mkshmirbsd.org
close 952970
thanks
>This isn’t a packaging bug, so I’ll probably close this, but we can
>discuss this upstream.
Closing as announced, but I’ve added it to the plans:
http://www.mirbsd.org/mksh.htm#plans
PS:
Aleksey Cheusov dixit:
>Well, to be honest I haven't check ksh88. But '+' sign is allowed for
>aliases in ksh (on NetBSD, Solaris), /bin/sh on FreeBSD, ksh93, dash,
^ pdksh ^ ksh93^ ash ^ ash
>pdksh, bash, zsh etc.
Yes, but, as I said, we had to
Mingye Wang dixit:
>Mksh is unable to handle Unicode characters that are not in the BMP
(It’s “mksh”, lowercase ‘m’.)
Only short because I’m in a meeting: yes, and this is deliberate at
the moment, because mksh is the shell of MirBSD which uses 16-bit
Unicode.
I noticed the interactive
This totally makes sense in mksh only.
$ i=4+4; echo $i
This is an assignment of the string "4+4" to the variable i. The string
is then, between assignment and storage, parsed as an arithmetic
expression, because i is of integer type. The expression is calculated
and the result stored.
$ i=i+1;
Warning reporting during running of a script is supremely hard, you
cannot use any file descriptors; basically, you have to reserve one with
a high number for syslog and do it that way and hope someone reads
syslog… so I never did. We really need a linting shell runner or
something ☹
--
You
** Changed in: mksh
Status: New => Fix Committed
--
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/1857826
Title:
mksh isglobal ASAN
fix is making it to the anoncvs and github mirrors within the hour
** Changed in: mksh
Status: Triaged => Fix Committed
--
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
Martijn Dekker dixit:
> I noticed something strange while executing some 'eval'-ed commands: the -e/-o
> errexit appears to become active out of nowhere.
>
> $ mksh -c 'echo $-; eval '\''echo $-'\''; echo $-'
> hc
> ehc
> hc
Found to be caused by reusing bit7 of the ERREXIT flag for
nefarious
As discussed heavily on IRC, other shells can use ((…)) or let to work
like mksh, and the mksh behaviour is semantically correct. I’ve
documented this in more detail in the manual page and the mksh FAQ now
but kept the behaviour as to not break older scripts written in mksh.
You might wish to
** Changed in: mksh
Importance: Undecided => High
** Changed in: mksh
Status: New => Triaged
** Changed in: mksh
Assignee: (unassigned) => Thorsten Glaser (mirabilos)
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribe
** Changed in: mksh
Importance: Undecided => Medium
** 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-t
and it’s most definitely not emulation of ksh93
some ksh88 and little parts of ksh93, but e.g. no float and other crap
or complicated things
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions:
01 in an integer variable is still 1 on output (010 may be 10 or 8
depending on the posix flag)
more later
--
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
: 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/1857195
Title:
here string behaviour
Erm… that’s right, += is string concatenation.
Write “let” before the line to make it integer addition.
--
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
“it should be deterministic/always the same” this is a very good point,
and at this, well, point, I’ve not yet got any opinion.
I modelled the here strings after here documents: first, the first two
“<<” are parsed indicating it’s a here document, then the here document
delimiter is parsed; if
Almost a good point, considering…
$ x=(a 'b c')
$ IFS=,
$ a="${x[*]}"; print -r -- "<$a>"
$ a="${x[@]}"; print -r -- "<$a>"
$ a=${x[*]}; print -r -- "<$a>"
$ a=${x[@]}; print -r -- "<$a>"
$ a="${u:-"${x[*]}"}"; print -r -- "<$a>"
$ a="${u:-"${x[@]}"}"; print -r -- "<$a>"
Oh the other hand,
Args, hit Return too early.
- contact me in IRC or so if you’re up for SMTP debugging
-
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02
for the POSuX reference
--
You received this bug notification because you are a member of mksh
Mailing List, which is
Not a definite decision, but consider this:
print -r -- "${x[@]}"
- vs. -
a="${x[@]}"
In the first code, the elements of array x are expanded in list context,
that is, each element as separate word, unset elements generating no
words.
In the second code, the elements are expanded in scalar
np you’re welcome
Note that this is special-cased (but easy enough to do and justify in
that place).
The variable must be set and have its content dynamically allocated
(normally so for strings previously set), not a special variable (like
IFS, PATH, etc.), not an integer variable, and not have
Please wait a bit until the anoncvs mirror has caught up. Thanks!
--
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/1855167
Title:
Comparatively
Duplicate of https://bugs.launchpad.net/mksh/+bug/1783355
** Changed in: mksh
Status: New => Invalid
--
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
nee: (unassigned) => Thorsten Glaser (mirabilos)
** Changed in: mksh
Status: New => Confirmed
--
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
Dixi quod…
>┌──┬┬──┬┬──┐
>│ shell \ what │ inside visible │ exported │ afterwards visible │ exported │
>├──┼┼──┼┼──┤
>│ ksh93│ ✔ as required │ ✗ (ok) │ ✗ no,
Martijn Dekker dixit:
> One of the recent commits introduced a new bug: if a dot script is sourced
> with
> 'command .', the positional parameters are permanently overridden by whatever
> they were at the point of sourcing, and any changes to them are ignored.
Ouch, so it’s not all that easy…
Martijn Dekker dixit:
> The 'readonly' and 'export' commands exit the shell on error even if
> they are prefixed with 'command', which should stop that exit from
> happening.
tricky but fixed, thanks
//mirabilos
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was
Martijn Dekker dixit:
> Expected output:
>
> longargs.sh[8]: /bin/sh: Argument list too long
> status 126
merged, thanks
Martijn Dekker dixit:
>$ mksh -c 'command set -- one two three; printf %s\\n "$@"'
fixed, thanks
Hi Martijn,
> Currently, when a utility fails to execute due to something like E2BIG, mksh
> sets the exit status to 1. That is not satisfactory because there is no way to
agreed; thanks for the patch, it’s consistent, will apply.
bye,
//mirabilos
--
21:12⎜ sogar bei opensolaris haben die von
I changed the error message, as indicated.
** Changed in: mksh
Status: Opinion => 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
I don’t consider it a bug.
If you break stat(2) in your system, expect follow-up breakage, as per
the GIGO principle.
--
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
I vaguely recall something about access() succeeding for file foo when
foo.exe exists on some platforms, or the other way round, and that the
modes are also not always correct. The manpage supports the latter…
Even if a process has appropriate privileges and indicates success for
X_OK,
On unix. test whether a file exists is done using stat. access is not
portable and buggy on many platforms.
Honestly, write your security policies to not block stat. I’m not even
going to bother with this one.
** Changed in: mksh
Importance: Undecided => Wishlist
** Changed in: mksh
“5) A failure of the stat() system call is not an accurate indicator of
the exec()-ability of the file. The only way to determine if a file is
executable is to execute it.”
This is not generally true. We need to check for +x, and there was
something with strange operating systems, *and* the shell
stat() must always succeed, because we must check that the executable
bits are set before accepting the file as command (if not for anything
else, then because POSIX was changed to demand distinguishing $? between
126 and 127 for these cases).
--
You received this bug notification because you
What do you think of “not found or inaccessible”? (I hope I spelt that
right.)
--
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/1817789
Title:
No.
When you do
mksh -c /tmp/d/f
you ask mksh to find it as a command. The “not found” error message there is
more general; for example, it also happens if the interpreter is not found:
print '#!/nonexistent-int' >/tmp/ff
chmod 755 /tmp/ff
mksh -c /tmp/ff
(This even results in
Hi John,
> It seems I might have come across an actual bug this time :-)
perhaps ;) But thanks for writing anyway, it’s always nice to
see what users run into.
> From the man page:
>
> kill-region: ^W
> Deletes the input between the cursor and the mark.
But also from the
This is, unfortunately, by design.
I’ve committed a manpage change (in CAVEATS) with a rationale, though.
** Changed in: mksh
Status: Triaged => Invalid
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching
>I still cannot confirm either way, but some preliminary research
>with an extended test script:
I’ve found something interesting:
tg@blau:~ $ mksh -c 'echo a; (trap -- "echo subshell_exit >&2" EXIT); echo b'
a
b
tg@blau:~ $ mksh -c 'echo a; (trap -- "echo subshell_exit >&2" EXIT;); echo b'
a
b
Hi John,
>> no, you’ve discovered you did not read the manpage ☺
>
> I did read it, but I didn't understand it...! Adding the \r and surrounding
> all escape sequences with \1 solves my problem, but I don't understand why
> (?).
Ah okay.
Basically, the first \1\r says: make the \1 into a
Hi John,
> I think I've discovered a bug in mksh. According to the man page:
no, you’ve discovered you did not read the manpage ☺
PS1 The primary prompt for interactive shells. Parameter, com-
[…]
Since backslashes and other special characters may be inter-
Hoi Martijn,
> they are prefixed with 'command', which should stop that exit from
> happening.
Almost certainly a bug (from what I remember without needing to
look it up), indeed.
> Test cases:
Thanks! Putting this on my TODO.
bye,
//mirabilos
--
“ah that reminds me, thanks for the stellar
Calvin Crowley dixit:
>mksh: /etc/profile.d/PackageKit.sh[14]: syntax error: unexpected
>operator/operand '=~'
Please report this as a bug against the PackageKit packaging in
Fedora instead. Make clear that files in /etc/profile.d/ can be
sourced by any POSIX sh-compatible shell and thus MUST
so that the loop always has $?=0, or:
while :; do
IFS=' ' read a b || break
Interestingly enough, removing the “| sort -u” also makes it work.
** Affects: mksh
Importance: Medium
Assignee: Thorsten Glaser (mirabilos)
Status: Triaged
--
You received this
The entire tree printing code is currently not suited for that, a major
rewrite is needed.
--
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/1783355
** Changed in: mksh
Status: New => 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/1719035
Title:
mksh.htm "Patching" section
** Changed in: mksh
Status: Triaged => Fix Committed
--
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/1779179
Title:
nōn-ASCII heredoc
Found to be not a bug:
$ i=42; : ${var#${q[i=777]}}; echo $i; var=meow; : ${var#${q[i=777]}};
echo $i
must return 777 twice, because the pattern must always be expanded
before looking at $var.
$ i=42; : ${var+${q[i=777]}}; echo $i; var=meow; : ${var+${q[i=777]}};
echo $i
already behaves
Public bug reported:
“If word is not needed, it shall not be expanded.” (POSIX)
00:52 < izabera> i=42; : ${var#${q[i=777]}}; echo $i; var=meow; :
${var#${q[i=777]}}; echo $i
00:52 < izabera> prints 42 777 in bash and ksh93
00:52 < izabera> and 777 777 in mkmsh
The #/##/%/%% of course need to
Bernd Schumacher dixit:
>Please confirm, that this is a bug and not the expected behaviour of mksh.
I still cannot confirm either way, but some preliminary research
with an extended test script:
$ cat script
fkt()
{
trap -- "echo $1 >&2" EXIT
}
fkt shell_exit
$(fkt fn_exit)
$(trap -- "echo
Public bug reported:
The following construct causes a zombie to hang around:
#!/bin/sh
cd /home/tglase/Misc/vpn.w
(sleep 20; sudo route -n add -host x.x.x.x gw 172.28.0.1) &
exec sudo openvpn --config /home/tglase/Misc/vpn.w/vpn-bn-01.ovpn "$@"
Adding an “exec” before the sudo in the subshell
Public bug reported:
tglase@tglase:~ $ mksh x
Foo
BlA9907BAr
try2
x: syntax error: unexpected '|'
1|tglase@tglase:~ $ bash x
Foo
BlA9910BAr
try2
tglase@tglase:~ $ ksh93 x
Foo
BlA9917BAr
try2
** Affects: mksh
Importance: Medium
Status: Triaged
** Attachment added: "bug
Syntax is valid POSuX as per https://stackoverflow.com/a/7046926/2171120
--
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/1783355
Title:
here
Seb dixit:
>As if '-m' was just ignored.
It gets worse: if “-m” is passed, interactive is also broken.
I’ve tracked this down to between pdksh 4.0 (usenet posting)
and pdksh-5.0.6.tar.gz, even the changelog entry I believe
responsible, and I agree it’s probably a thinko instead of
intended
Hi again,
>Thinking a bit more about this, I found a valid reason not to keep the
>terminal state after a restarted job exits (successfully): the tty
>state in which that job was started can be obsolete at the time it is
>restarted because the tty state may have been modified while the job was
G.raud Meyer dixit:
>First one should know what is the correct behaviour. The feature of
[…]
>Before a patch fixing the strange case of a "successful but temporarily
>stopped job has failed" it would be good to document the feature (and
>the bug, if it is one).
I honestly don’t know.
It is
Hoi Martijn,
>Here's a patch.
Indeed. Thanks, applied.
I’ll look at your other and Stéphane’s bugreport once I’m over
the current edition of the “common cold” ☹
Much appreciated,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to
No.
They’re ugly enough in C, and they can easily be transformed into
something portable:
for ((a; b; c)); do
blah
done
↓
(( a ))
while (( b )); do
blah
(( c ))
done
So, *really*, no. I’m translating for loops in C source into while loops
as I go,
Hi,
>for better support of the UTF-8 mode of the mksh I've done a small
>patch which enables the mksh to change to UTF-8 mode even if the
>locale is changed at runtime ', e.g in ~/.profile, ~/.mkshrc or
>in the system wide /etc/profile. The attached patch is for R54.
locale tracking is on the
Dr. Werner Fink dixit:
>> Just to make sure: this is with LTO disabled?
>... AFAICS ftom the build log the link-time optimizer is not disabled
Just a short look, don't have much time atm:
call Build.sh *without* "-c lto".
>> This will indicate it uses those functions instead of the
>> arrays
Dr. Werner Fink dixit:
>Morning Thorsten,
Morning ☺
>On Wed, Nov 22, 2017 at 12:42:52AM +, Thorsten Glaser wrote:
>> what’s -D_DEFAULT_SOURCE for?
> -- Macro: _DEFAULT_SOURCE
> If you define this macro, most features are included apart from
> X/Open, L
Hi,
>HAVE_SYS_SIGLIST=0
>HAVE_SYS_ERRLIST=0
>HAVE_SYS__SIGLIST=0
>HAVE_SYS__ERRLIST=0
>export HAVE_SYS_SIGLIST HAVE_SYS_ERRLIST HAVE_SYS_SIGLIST HAVE_SYS__ERRLIST
you have no less than *three* mistakes in there ;)
1. You export HAVE_SYS_SIGLIST twice (second one is missing the
extra
Martijn Dekker dixit:
>> I’ll put the issue on my TODO only, for now, but thanks anyway.
>
>We're at R56 now but nothing seems to have changed here. Status?
It’s on the TODO.
bye,
//mirabilos
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that
Hi Larry,
>In mksh R56, with 'set -o vi' in effect, entering '0' no longer
>moves the cursor to the beginning of the line. That seems like a
thanks, indeed a regression, fixed in commitid 10059A356DB182F3791.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
According to multiplexd this is likely fixed in R56. If not, pleas e
open a new issue.
** Changed in: mksh
Status: New => Fix Released
--
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions:
It’s known that mksh’s testsuite exhibits problems in the infrastructure
(kernel, libraries, toolchain, compiler).
In this case, GCC’s LTO (and before that, -fwhole-program --combine) is
a repeat offender of breaking code.
If your builds exhibit this problem, you should *disable LTO for your
Robert Elz dixit:
>there is no right answer - and that the only rational result is that portable
>scripts cannot expect to be able to exec a function (or any builtin that is
Yes, but the others in this thread want to allow portable scripts
to rely on the exec builtin always resulting in a PATH
Martijn Dekker dixit:
>> And this is utter nonsense, the builtin does replace the shell process,
>
>No. On mksh, 'exec builtin' is exactly equivalent to 'builtin; exit'.
>The builtin is run in the existing shell process. No
>replacing/overlaying of the shell process takes place. It's easy to
Robert Elz dixit:
> | This specifically means that builtins MAY be made available
> | to exec, and that thatb s an expected modus operandi.
>
>It means nothing of the kind. The System Interfaces volume of POSIX.1-2008
>is the part that defines the system calls.
There’s no “exec” system
Martijn Dekker dixit:
>And under what theory should 'exec' run a shell function?
Read up on what a “command” can be, pretty far up in
the Shell part.
Although I did not manage to get a pipeline or loop run.
Not sure if that’s a bug, but looking at the way statements
are parsed, probably not.
Martijn Dekker dixit:
>to be a bug in POSIX terms; 'exec' is supposed to launch a program that
>overlays the current shell[2], implying the program launched by 'exec'
>is always external to the shell.
The built-in utility is “the program implementing command”,
and, with exec, it is not returning
Martijn Dekker dixit:
>This behaviour also appears to be contrary to the documentation in
>mksh(1) ("The command is executed without forking, replacing the shell
>process"). The test script below demonstrates that neither "exec"
And this is utter nonsense, the builtin does replace the shell
Public bug reported:
Natureshadow reports that, when having multiple parallel mksh sessions
that share the same HISTFILE, after exiting one of them and then
starting a new one, the history from the shell just terminated is not
available.
We currently believe this is due to history truncation
Hi Steffen,
>i think, the \r is expanded, the output is
a bit unsure what exactly you’re talking about, but you cannot
ever use echo to display strings portably.
Use 'print -r -- "$foo"' to display the contents of the foo parameter.
Is there anything you think mksh fails to do correctly? If
Daniel Richard G. dixit:
>While UTF-8 isn't a thing in the z/OS environment, I think there could
>be value in printing something that will be converted by the existing
>EBCDIC->ASCII terminal/NFS conversion into correctly-formed UTF-8
>characters.
[…]
>in the terminal. Effectively an
Daniel Richard G. dixit:
[…]
>but that's about it.
OK.
>Note that "cc" isn't even the same type of compiler as xlc. The option
>syntax is different/incompatible, for starters.
It’s likely still an xlc frontend, as it’s detected as xlc.
>I saw that you put in a change to use xlc on this
Hi,
I’m starting a new thread so I can archive the old one.
I’ve merged most of your patch, only did some things differently.
I also added your copyright to misc.c which had the most logic
from you; feel free to send patches to change your copyright info
on files you feel you have co-authorship
mksh’s globbing really sucks. Way out: parse them as special kind of
regex (NFA with making $KSH_MATCH an array, possibly).
References:
- https://research.swtch.com/glob
- https://swtch.com/~rsc/regexp/regexp1.html
--
You received this bug notification because you are a member of mksh
Mailing
1 - 100 of 267 matches
Mail list logo
