Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Thorsten Glaser
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
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Daode
Thorsten Glaser  wrote:
 |Steffen Daode Nurpmeso dixit:
 |>  @(#)MIRBSD KSH R43 2013/02/19
 |[…]
 |>May have something to do with my rebased amateurish CNTRL-C SIGINT
 |>patch?  Hmm, don't think so ,)
 |
 |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).

 |bye,
 |//mirabilos

Fine,

--steffen


Re: Job status will not be updated

2013-05-02 Thread Daode
Thorsten Glaser  wrote:
 |Steffen Daode Nurpmeso dixit:
 |
 |>Thorsten Glaser  wrote:
 |>|I’m in the process of becoming awake.
 |>
 |>That is *really* good news, mksh(1) is the best.
 |
 |;-)
 |
 |>Another one…
 |
 |Mh. It’s not so nice to hijack the thread, but it’s done in
 |Usenet all the time, so…

Ok.

--steffen


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Thorsten Glaser
Steffen Daode Nurpmeso dixit:

>No, the test was on emacs without e and s … aaand

Haha ;-)

>  @(#)MIRBSD KSH R43 2013/02/19
[…]
>May have something to do with my rebased amateurish CNTRL-C SIGINT
>patch?  Hmm, don't think so ,)

Please, if you patch mksh, append a space and a “vendor string”
to KSH_VERSION, like PLD:
http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/mksh/mksh-distro.patch?revision=1.6&view=markup
Or Debian stale (first part of):
https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/mksh/check.t.diff?r1=text&tr1=1.13&r2=text&tr2=1.15.2.2
And (also first part of):
https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/mksh/sh.h.diff?r1=text&tr1=1.1.221.8&r2=text&tr2=1.15.2.2

>Sorry for the noise, then!

OK, no problem.

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)


Re: Job status will not be updated

2013-05-02 Thread Thorsten Glaser
Steffen Daode Nurpmeso dixit:

>Thorsten Glaser  wrote:
> |I’m in the process of becoming awake.
>
>That is *really* good news, mksh(1) is the best.

;-)

>Another one…

Mh. It’s not so nice to hijack the thread, but it’s done in
Usenet all the time, so…

That one can’t be fixed as the state only changes if SIGCHLD
is gotten, which is only when the child exits or gets stopped.

bye,
//mirabilos
-- 
Sorry,  I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like  systemd,  feminism
or social democracy.
-- Christoph Lohmann on d...@suckless.org


Re: Job status will not be updated

2013-05-02 Thread Daode
Steffen "Daode" Nurpmeso  wrote:
 |Thorsten Glaser  wrote:
 ||I’m in the process of becoming awake.
 |
 |That is *really* good news, mksh(1) is the best.
 |
 |Another one…
 |
 |  ?0[steffen@sherwood tmp]$ play SONG &
 |  ?0[steffen@sherwood tmp]$ jobs
 |  [1] + Running  play /Use...wagner.2001-08-05.ogg
 |  ?0[steffen@sherwood tmp]$ kill -TSTP %1
 |  ?0[steffen@sherwood tmp]$ jobs
 |  [1] + Suspended (signal)   play /Use...wagner.2001-08-05.ogg
 |  ?0[steffen@sherwood tmp]$ kill -CONT %1
 |  ?0[steffen@sherwood tmp]$ jobs
 |  [1] + Suspended (signal)   play /Use...wagner.2001-08-05.ogg

Seems still to be true for R45 except for the different message
(without „ (signal)“), though.

--steffen


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Daode
Thorsten Glaser  wrote:
 |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?

No, the test was on emacs without e and s … aaand

  @(#)MIRBSD KSH R43 2013/02/19

I'm currently building on brand new OpenBSD 5.3, please be
patient…  ps:

  ?1[steffen@obsd steffen]$ echo $KSH_VERSION
  @(#)MIRBSD KSH R45 2013/04/26
  ?0[steffen@obsd steffen]$ unset KSH_VERSION   
   
  mksh: read-only: KSH_VERSION
  ?1[steffen@obsd steffen]$

Indeed it doesn't happen with R45.
May have something to do with my rebased amateurish CNTRL-C SIGINT
patch?  Hmm, don't think so ,)

Sorry for the noise, then!

 |bye,
 |//mirabilos

Ciao!  (mksh! mksh! ,)

--steffen


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Thorsten Glaser
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


Job status will not be updated

2013-05-02 Thread Daode
Thorsten Glaser  wrote:
 |I’m in the process of becoming awake.

That is *really* good news, mksh(1) is the best.

Another one…

  ?0[steffen@sherwood tmp]$ play SONG &
  ?0[steffen@sherwood tmp]$ jobs
  [1] + Running  play /Use...wagner.2001-08-05.ogg
  ?0[steffen@sherwood tmp]$ kill -TSTP %1
  ?0[steffen@sherwood tmp]$ jobs
  [1] + Suspended (signal)   play /Use...wagner.2001-08-05.ogg
  ?0[steffen@sherwood tmp]$ kill -CONT %1
  ?0[steffen@sherwood tmp]$ jobs
  [1] + Suspended (signal)   play /Use...wagner.2001-08-05.ogg

Just a nit. :-)

--steffen


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Thorsten Glaser
Steffen Daode Nurpmeso dixit:

>hmhmm, 2.8.1 says indeed ,)
[…]
>  In all of the cases shown in the table, an interactive shell shall
>  write a diagnostic message to standard error without exiting.

Okay, so this is probably correct (to abort) except in
an interactive shell. Thanks for digging out that one,
I’m in the process of becoming awake.

>But clarification by POSIX is possibly undesirable :)

Right ;)

I’ll change this to not abort for interactive shells then.

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Daode
Thorsten Glaser  wrote:
 |Steffen Daode Nurpmeso dixit:
 |
 |…
 |Well, don’t do that then.

That is indeed the point at which i'm guilty.

 |tg@blau:~ $ mksh -c 'unset KSH_VERSION'
 |mksh: read-only: KSH_VERSION
 |
 |>I'd consider this a bug, since POSIX says „Read-only variables
 |>cannot be unset“ but i fail to see why this should result in
 |>anything more than $? being 1, especially without set -e?
 |
 |unset is a POSIX special built-in utility. It says:

 |EXIT STATUS
 |
 |0
 |  All name operands were successfully unset.
 |>0
 |  At least one name could not be unset.
 |
 |CONSEQUENCES OF ERRORS
 |
 | Default.
 […]
 |
 |There are even checks in the testsuite for that, so you’d probably
 |better accept this and move on and just Don’t Do That Then ;-)

hmhmm, 2.8.1 says indeed ,)

  For a non-interactive shell, an error condition encountered by
  a special built-in (see Special Built-In Utilities) or other
  type of utility shall cause the shell to write a diagnostic
  message to standard error and exit as shown in the following
  table:
  […]
  In all of the cases shown in the table, an interactive shell shall
  write a diagnostic message to standard error without exiting.

 |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

But clarification by POSIX is possibly undesirable :)
I'll keep on hanging around sofar, ciao,

--steffen


Re: "$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Thorsten Glaser
Steffen Daode Nurpmeso dixit:

…
Well, don’t do that then.

tg@blau:~ $ mksh -c 'unset KSH_VERSION'
mksh: read-only: KSH_VERSION

>I'd consider this a bug, since POSIX says „Read-only variables
>cannot be unset“ but i fail to see why this should result in
>anything more than $? being 1, especially without set -e?

unset is a POSIX special built-in utility. It says:

EXIT STATUS

0
  All name operands were successfully unset.
   >0
  At least one name could not be unset.

CONSEQUENCES OF ERRORS

 Default.

And, for special built-in utilities:

1. A  syntax  error  in a special built-in utility may cause a shell
   executing  that utility to abort, while a syntax error in a regular
   built-in  utility shall not cause a shell executing that utility to
   abort.  (See [229]Consequences of Shell Errors for the consequences
   of  errors on interactive and non-interactive shells.) If a special
   built-in  utility  encountering  a  syntax error does not abort the
   shell, its exit value shall be non-zero.

On the other hand, I don’t know whether it’s a syntax error or not…
but then, it’s been always this way:

tg@blau:~ $ mksh-R20 -c 'readonly foo=bar; unset foo; echo bla'; echo $?
mksh-R20: unset: foo is read only
1

There are even checks in the testsuite for that, so you’d probably
better accept this and move on and just Don’t Do That Then ;-)

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: 'rename' in mksh ?

2013-05-02 Thread John Chludzinski
 $(whence -p rename) .cpp .cc *.cpp

Works like a charm.  Thanks!

---John

On Wed, May 1, 2013 at 6:11 PM, Thorsten Glaser  wrote:
> John Chludzinski dixit:
>
>>In Cygwin/bash 'rename' is available:
>>
>>$ rename .cpp .cc *.cpp
>
> You probably installed some tool that runs as /usr/bin/rename[.exe]
> which is not normally shipped on Berkeley Unix systems.
>
>>Why was this necessary?
>
> The entire story involves an mv(1) dynamically linked against µClibc
> in a remote location on a production system and the attempt to upgrade
> µClibc with a UTF-8 capable (IIRC) version in situ.
>
> That very same day, mksh gained the following built-in command:
>  rename [--] from to
> Renames the file from to to. Both must be complete pathnames and
> on the same device. This builtin is intended for emergency situa-
> tions where /bin/mv becomes unusable, and directly calls
> rename(2).
>
> The name was chosen as “rename” because it’s not exactly “mv”, nothing
> provided “rename” on MirBSD or FreeWRT (or other operating systems I’ve
> tried at that time), and it was deemed that others would not as easily
> conflict with this as with the shorter “ren”.
>
> I only became aware of the existence of a third-party tool called
> “rename” last year or so. But, SOL. mksh has had rename for ages
> (something like 2006).
>
> By the way, this would work:
> $(whence -p rename) .cpp .cc *.cpp
>
> Or probably:
> /usr/bin/rename .cpp .cc *.cpp
>
> You can even tabcomplete the latter.
>
> This is no different from other builtins, like true, false, [ and test,
> where the version the shell ships takes precedence over the version the
> OS ships (e.g. there’s a GNU false that takes --version and --help…).
>
> bye,
> //mirabilos
> --
> Sorry,  I’m annoyed today and you came by as an Arch user. These are the
> perfect victims for any crime against humanity, like  systemd,  feminism
> or social democracy.
> -- Christoph Lohmann on d...@suckless.org


"$ unset KSH_VERSION" quits login shell

2013-05-02 Thread Daode
… luckily the same inside a startup file doesn't cause any
trouble, just as OpenBSD's ksh(1).
I'd consider this a bug, since POSIX says „Read-only variables
cannot be unset“ but i fail to see why this should result in
anything more than $? being 1, especially without set -e?
Maybe even worth a POSIX clarification?
Is that some historical issue thing?
Ciao,

--steffen