20
I Use This!
Moderate Activity

News

Analyzed about 11 hours ago. based on code collected 1 day ago.
Posted over 8 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R52 was published today. While there are still several known bugs, this is a release that primarily fixes lots of these, and, as with R51, we have no known regressions. Some of the itinerary for R52 has moved to R53 ... [More] instead, as some bugfixes change the shell language and thus warrant a new major version, which is why this is not R51b, and they accumulated and could use some testing ;-) This release has a nōnzero chance to break existing scripts that use some extension features – I had to quote some tildes in dot.mkshrc and a variable expansion in ${x/y"$z"} in MirWebseite (the $z) – twice!. As usual, test! In less related news, a new release of the FixedMisc [MirOS] font is available (in BDF form and no conflict with the system Fixed [Misc] font); our CVS has the sources in bdfctool(1) format. [Less]
Posted over 8 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R52 was published today. While there are still several known bugs, this is a release that primarily fixes lots of these, and, as with R51, we have no known regressions. Some of the itinerary for R52 has moved to R53 ... [More] instead, as some bugfixes change the shell language and thus warrant a new major version, which is why this is not R51b, and they accumulated and could use some testing ;-) This release has a nōnzero chance to break existing scripts that use some extension features – I had to quote some tildes in dot.mkshrc and a variable expansion in ${x/y"$z"} in MirWebseite (the $z) – twice!. As usual, test! In less related news, a new release of the FixedMisc [MirOS] font is available (in BDF form and no conflict with the system Fixed [Misc] font); our CVS has the sources in bdfctool(1) format. [Less]
Posted over 8 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R52 was published today. While there are still several known bugs, this is a release that primarily fixes lots of these, and, as with R51, we have no known regressions. Some of the itinerary for R52 has moved to R53 instead ... [More] , as some bugfixes change the shell language and thus warrant a new major version, which is why this is not R51b, and they accumulated and could use some testing ;-) This release has a nōnzero chance to break existing scripts that use some extension features – I had to quote some tildes in dot.mkshrc and a variable expansion in ${x/y"$z"} in MirWebseite (the $z) – twice!. As usual, test! In less related news, a new release of the FixedMisc [MirOS] font is available (in BDF form and no conflict with the system Fixed [Misc] font); our CVS has the sources in bdfctool(1) format. [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R51 was published today. This is a feature release clearly, but still something a lot of people would wish to use. It contains several known severe bugs, but they all are no regressions, i.e. they exist in R50f already. ... [More] This one is kinda an early release, as I wish to have those known issues all fixed, but the changes – both deep down and enduser-visible – already warrant people looking for breakages, plus it makes synchronisation with mksh-os2 easier. mksh R52 will follow, as bugfix release, pretty soon. Itinerary: Fixes for as much of these known bugs as possible (code rewrites) Unicode 8 New feature: print -a Fixes for bugs reported against R51 Possibly more EBCDIC and OS/2 code synchronisation Maybe a dead useful debug tool… Once that’s out, I’ll roll up the fixes into R50g, so that particular code branch is not dead yet either ☺ And afterwards, at least mksh(1)-wise – I have got a lot of other things on my plate after all – we can attempt getting EBCDIC and maybe OS/2 to a state where the code is included in CVS. [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R51 was published today. This is a feature release clearly, but still something a lot of people would wish to use. It contains several known severe bugs, but they all are no regressions, i.e. they exist in R50f already. This ... [More] one is kinda an early release, as I wish to have those known issues all fixed, but the changes – both deep down and enduser-visible – already warrant people looking for breakages, plus it makes synchronisation with mksh-os2 easier. mksh R52 will follow, as bugfix release, pretty soon. Itinerary Fixes for as much of these known bugs as possible (code rewrites) Unicode 8 New feature: print -a Fixes for bugs reported against R51 Possibly more EBCDIC and OS/2 code synchronisation Maybe a dead useful debug tool… Once that’s out, I’ll roll up the fixes into R50g, so that particular code branch is not dead yet either ☺ And afterwards, at least mksh(1)-wise – I have got a lot of other things on my plate after all – we can attempt getting EBCDIC and maybe OS/2 to a state where the code is included in CVS. [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R51 was published today. This is a feature release clearly, but still something a lot of people would wish to use. It contains several known severe bugs, but they all are no regressions, i.e. they exist in R50f already. ... [More] This one is kinda an early release, as I wish to have those known issues all fixed, but the changes – both deep down and enduser-visible – already warrant people looking for breakages, plus it makes synchronisation with mksh-os2 easier. mksh R52 will follow, as bugfix release, pretty soon. Itinerary: Fixes for as much of these known bugs as possible (code rewrites) Unicode 8 New feature: print -a Fixes for bugs reported against R51 Possibly more EBCDIC and OS/2 code synchronisation Maybe a dead useful debug tool… Once that’s out, I’ll roll up the fixes into R50g, so that particular code branch is not dead yet either ☺ And afterwards, at least mksh(1)-wise – I have got a lot of other things on my plate after all – we can attempt getting EBCDIC and maybe OS/2 to a state where the code is included in CVS. [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
The MirBSD Korn Shell R51 was published today. This is a feature release clearly, but still something a lot of people would wish to use. It contains several known severe bugs, but they all are no regressions, i.e. they exist in R50f already. This ... [More] one is kinda an early release, as I wish to have those known issues all fixed, but the changes – both deep down and enduser-visible – already warrant people looking for breakages, plus it makes synchronisation with mksh-os2 easier. mksh R52 will follow, as bugfix release, pretty soon. Itinerary: Fixes for as much of these known bugs as possible (code rewrites) Unicode 8 New feature: print -a Fixes for bugs reported against R51 Possibly more EBCDIC and OS/2 code synchronisation Maybe a dead useful debug tool… Once that’s out, I’ll roll up the fixes into R50g, so that particular code branch is not dead yet either ☺ And afterwards, at least mksh(1)-wise – I have got a lot of other things on my plate after all – we can attempt getting EBCDIC and maybe OS/2 to a state where the code is included in CVS. [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
carstenh asked in IRC how to make a shebang for mksh(1) scripts that works on both regular Unix and Android. This is not as easy as it looks, though. Most Unicēs will have mksh installed, either manually or by means of the native package system ... [More] , as /bin/mksh. Some put it into package manager-specific directories; I saw /sw/bin/mksh, /usr/local/bin/mksh and /usr/pkg/bin/mksh so far. Some systems have it as /usr/bin/mksh but these are usually those who got poettering’d and have /bin a symlink anyway. Most of these systems also have env(1) as /usr/bin/env. Android, on the contrary, ships with precisely one shell. This has been mksh for a while, thankfully. There is, however, neither a /bin nor a /usr directory. mksh usually lives as /system/bin/mksh, with /system/bin/sh a symlink(7) to the former location. Some broken Android versions ship the binary in the latter location instead and do not ship anything that matches mksh on the $PATH, but I hope they merge my AOSP patch to revert this bad change (especially as some third-party Android toolkits overwrite /system/bin/sh with busybox sh or GNU bash and you’d lose mksh in the progress). However, on all official Android systems, mksh is the system shell. This will be important later. The obvious and correct fix is, of course, to chmod -x the scripts and call them explicitly as mksh scriptname. This is not always possible or desirable; sometimes, people will wish it to be in the $PATH and executable, so we need a different solution. There’s a neat trick with shebangs – the absence of one is handled specifically by most systems in various ways. I remember reading about it, but don’t remember where; I can’t find it on Sven Mascheck’s excellent pages… but: the C shell variants run a script with the Bourne Shell if its first line is a sole colon (‘:’), the Bourne family shells run it with themselves or ${EXECSHELL:-/bin/sh} in those cases, and the kernel with the system shell, AFAIK. So we have a way to get most things that could call the script to interpret it as Bourne/POSIX shell script on most systems. Then we just have to add a Bourne shell scriptlet that switches to mksh iff the current shell isn’t it (lksh, or something totally different). On Android, there is only ever one shell (or the toolkit installer better preserve mksh as mksh), so this doesn’t do anything (I hope – but did not test – that the kernel invokes the system shell correctly despite it not lying under /bin/sh) nor does it need to. This leaves us with the following “shebang”: : case ${KSH_VERSION-} in *MIRBSD\ KSH*) ;; *) # re-run with The MirBSD Korn Shell, this is an mksh-specific script test "${ZSH_VERSION+set}" = set && alias -g '${1+"$@"}'='"$@"' exec mksh "$0" ${1+"$@"} echo >&2 E: mksh re-exec failed, should not happen exit 127 ;; esac The case argument not only does not need to, but actually should not be quoted; the expansion is a set -u guard; the entire scriptlet is set -e safe as well; comments and expansions are safe. exec shall not return, but if it does (GNU bash violates POSIX that way, for example), we use POSIX’ appropriate errorlevel. zsh is funny with the Bourne shell’s way of using "$@" properly. But this should really be portable. The snippet is both too short and too obvious (“only way to do it”) to be protected by copyright law. Thanks to carstenh and Ypnose for discussing things like this with us in IRC, sending in bugfixes (and changes we decline, with reason), etc. – it feels like we have a real community, not just consuments ☺ [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
carstenh asked in IRC how to make a shebang for mksh(1) scripts that works on both regular Unix and Android. This is not as easy as it looks, though. Most Unicēs will have mksh installed, either manually or by means of the native package system ... [More] , as /bin/mksh. Some put it into package manager-specific directories; I saw /sw/bin/mksh, /usr/local/bin/mksh and /usr/pkg/bin/mksh so far. Some systems have it as /usr/bin/mksh but these are usually those who got poettering’d and have /bin a symlink anyway. Most of these systems also have env(1) as /usr/bin/env. Android, on the contrary, ships with precisely one shell. This has been mksh for a while, thankfully. There is, however, neither a /bin nor a /usr directory. mksh usually lives as /system/bin/mksh, with /system/bin/sh a symlink(7) to the former location. Some broken Android versions ship the binary in the latter location instead and do not ship anything that matches mksh on the $PATH, but I hope they merge my AOSP patch to revert this bad change (especially as some third-party Android toolkits overwrite /system/bin/sh with busybox sh or GNU bash and you’d lose mksh in the progress). However, on all official Android systems, mksh is the system shell. This will be important later. The obvious and correct fix is, of course, to chmod -x the scripts and call them explicitly as mksh scriptname. This is not always possible or desirable; sometimes, people will wish it to be in the $PATH and executable, so we need a different solution. There’s a neat trick with shebangs – the absence of one is handled specifically by most systems in various ways. I remember reading about it, but don’t remember where; I can’t find it on Sven Mascheck’s excellent pages… but: the C shell variants run a script with the Bourne Shell if its first line is a sole colon (‘:’), the Bourne family shells run it with themselves or ${EXECSHELL:-/bin/sh} in those cases, and the kernel with the system shell, AFAIK. So we have a way to get most things that could call the script to interpret it as Bourne/POSIX shell script on most systems. Then we just have to add a Bourne shell scriptlet that switches to mksh iff the current shell isn’t it (lksh, or something totally different). On Android, there is only ever one shell (or the toolkit installer better preserve mksh as mksh), so this doesn’t do anything (I hope – but did not test – that the kernel invokes the system shell correctly despite it not lying under /bin/sh) nor does it need to. This leaves us with the following “shebang”: : case ${KSH_VERSION-} in *MIRBSD\ KSH*) ;; *) # re-run with The MirBSD Korn Shell, this is an mksh-specific script test "${ZSH_VERSION+set}" = set && alias -g '${1+"$@"}'='"$@"' exec mksh "$0" ${1+"$@"} echo >&2 E: mksh re-exec failed, should not happen exit 127 ;; esac The case argument not only does not need to, but actually should not be quoted; the expansion is a set -u guard; the entire scriptlet is set -e safe as well; comments and expansions are safe. exec shall not return, but if it does (GNU bash violates POSIX that way, for example), we use POSIX’ appropriate errorlevel. zsh is funny with the Bourne shell’s way of using "$@" properly. But this should really be portable. The snippet is both too short and too obvious (“only way to do it”) to be protected by copyright law. Thanks to carstenh and Ypnose for discussing things like this with us in IRC, sending in bugfixes (and changes we decline, with reason), etc. – it feels like we have a real community, not just consuments ☺ [Less]
Posted almost 9 years ago by [email protected] (MirOS Developer tg)
carstenh asked in IRC how to make a shebang for mksh(1) scripts that works on both regular Unix and Android. This is not as easy as it looks, though. Most Unicēs will have mksh installed, either manually or by means of the native package system ... [More] , as /bin/mksh. Some put it into package manager-specific directories; I saw /sw/bin/mksh, /usr/local/bin/mksh and /usr/pkg/bin/mksh so far. Some systems have it as /usr/bin/mksh but these are usually those who got poettering’d and have /bin a symlink anyway. Most of these systems also have env(1) as /usr/bin/env. Android, on the contrary, ships with precisely one shell. This has been mksh for a while, thankfully. There is, however, neither a /bin nor a /usr directory. mksh usually lives as /system/bin/mksh, with /system/bin/sh a symlink(7) to the former location. Some broken Android versions ship the binary in the latter location instead and do not ship anything that matches mksh on the $PATH, but I hope they merge my AOSP patch to revert this bad change (especially as some third-party Android toolkits overwrite /system/bin/sh with busybox sh or GNU bash and you’d lose mksh in the progress). However, on all official Android systems, mksh is the system shell. This will be important later. The obvious and correct fix is, of course, to chmod -x the scripts and call them explicitly as mksh scriptname. This is not always possible or desirable; sometimes, people will wish it to be in the $PATH and executable, so we need a different solution. There’s a neat trick with shebangs – the absence of one is handled specifically by most systems in various ways. I remember reading about it, but don’t remember where; I can’t find it on Sven Mascheck’s excellent pages… but: the C shell variants run a script with the Bourne Shell if its first line is a sole colon (‘:’), the Bourne family shells run it with themselves or ${EXECSHELL:-/bin/sh} in those cases, and the kernel with the system shell, AFAIK. So we have a way to get most things that could call the script to interpret it as Bourne/POSIX shell script on most systems. Then we just have to add a Bourne shell scriptlet that switches to mksh iff the current shell isn’t it (lksh, or something totally different). On Android, there is only ever one shell (or the toolkit installer better preserve mksh as mksh), so this doesn’t do anything (I hope – but did not test – that the kernel invokes the system shell correctly despite it not lying under /bin/sh) nor does it need to. This leaves us with the following “shebang”: : case ${KSH_VERSION-} in *MIRBSD\ KSH*) ;; *) # re-run with The MirBSD Korn Shell, this is an mksh-specific script test "${ZSH_VERSION+set}" = set && alias -g '${1+"$@"}'='"$@"' exec mksh "$0" ${1+"$@"} echo >&2 E: mksh re-exec failed, should not happen exit 127 ;; esac The case argument not only does not need to, but actually should not be quoted; the expansion is a set -u guard; the entire scriptlet is set -e safe as well; comments and expansions are safe. exec shall not return, but if it does (GNU bash violates POSIX that way, for example), we use POSIX’ appropriate errorlevel. zsh is funny with the Bourne shell’s way of using "$@" properly. But this should really be portable. The snippet is both too short and too obvious (“only way to do it”) to be protected by copyright law. Thanks to carstenh and Ypnose for discussing things like this with us in IRC, sending in bugfixes (and changes we decline, with reason), etc. – it feels like we have a real community, not just consuments ☺ [Less]