gmane.os.miros.mksh

Re: mksh and plan9

Jens Staal — 2013-06-19T04:49:18

OK cool
added that to the patch.


Attached is a unified patch (ape diff -u) that builds using APE "cc" on 
Plan9. If anyone is interesting, also a binary+source (compiled with 
-DMKSH_NOPROSPECTOFWORK) archive can be downloaded at

http://plan9.bell-labs.com/sources/contrib/staal1978/pkg/mksh-R46.tbz

(warning, meant to be extracted directly at / ,so no directory first)

For my initial test of the NOPROSPECT... build is that it seems to work 
fine as a shell :)

Re: mksh and plan9

Thorsten Glaser — 2013-06-18T20:54:08

Jens Staal dixit:


Good guess!


The code checks for == 22.

I suppose I must change that into an offsetof check…
should be safe, as offsetof is already used in the code.

For now, make the “== NUM” into a “>= NUM”.


Me neither… the Lucent people seem to be dead or, worse,
working for Google on their “Issue 9” programming language
now. The 9front people are out of question, and others…
no idea – maybe cnuke< at > (who should be damn well reading
this mailing list ☺) could enlighten us.


If my rate of feedback is “rapid” even when I think I’m
on a slow streak… I guess I’m doing good and shouldn’t
pressurise myself just that much. Thanks! ☺

As for the job…
Could be worse. I get paid for system administration,
hacking PHP crap and dealing with Java™ Enterprise crap.
No surprises I am pretty “done” in the evenings.

But it lets me “play” enough, so it’s not half bad…
and it does pay the bills, barely.

bye,
//mirabilos

Re: mksh and plan9

Thorsten Glaser — 2013-06-18T19:56:11

Jens Staal dixit:


tg< at >herc:~ $ ./a.out
sizes: 4 4
ari_has_31_bit: 0 < 7FFFFFFF = 1
uari_has_31_bit: 0 < 7FFFFFFF = 1
uari_has_32_bit: 0 < FFFFFFFF = 1
uari_wrap_32_bit: FFFFFFFF > 0 = 1


No.

I suspect we have a different problem here.
Maybe struct padding.

---------------------------------------------------------------->8
#include <stdio.h>

struct ctasserts {
#define cta(name, assertion) char name[1]
/* this one should be defined by the standard */
cta(char_is_1_char, (sizeof(char) == 1) && (sizeof(signed char) == 1) &&
    (sizeof(unsigned char) == 1));
cta(char_is_8_bits, ((CHAR_BIT) == 8) && ((int)(unsigned char)0xFF == 0xFF) &&
    ((int)(unsigned char)0x100 == 0) && ((int)(unsigned char)(int)-1 == 0xFF));
/* the next assertion is probably not really needed */
cta(short_is_2_char, sizeof(short) == 2);
cta(short_size_no_matter_of_signedness, sizeof(short) == sizeof(unsigned short));
/* the next assertion is probably not really needed */
cta(int_is_4_char, sizeof(int) == 4);
cta(int_size_no_matter_o

Re: mksh and plan9

Jens Staal — 2013-06-18T19:19:36

Very nice that something I observed might be of help :)


OK I won't ;)


I modified attempt1 by changing from <stdint.h> to <inttypes.h> 
(stdint.h does not exist).

sorry if there are any typo's below (written over by hand from my VM)

under APE, running
cc -Dattempt1 -D_SUSV2_SOURCE thorsten-test.c : WORKS!

./a.out
sizes: 4 4
ari_has_31_bit: 0 < 7FFFFFFF = 1
uari_has_31_bit: 0 < 7FFFFFFF = 1
uari_has_32_bit: 0 < FFFFFFFF = 1
uari_wrap_32_bit: FFFFFFFF > 0 = 1

cc -Dattempt2 thorsten-test.c : FAIL
cc -Dattempt3 thorsten-test.c : WORKS!
./a.out gives the same output as attempt1

Any reason to also try gcc?


BTW: I checked the man pages of Plan9 diff and it does not have -u. On 
the other hand, APE got its own diff so I will test that one or else 
just copy my changed Build.sh to my host Linux and do the diff there.

I will add -DMKSH__NO_SETEUGID and -DMKSH_NOPROSPECTOFWORK to Plan9 
(since both ape/cc and gcc - compiled binaries suffer from the same 
issues regarding those two).

Re: mksh and plan9

Thorsten Glaser — 2013-06-18T18:40:21

Jens Staal dixit:


That will build lksh, not mksh, which is an entirely different thing.

But that means we know more closely which of the assertions fail(s):

#ifndef MKSH_LEGACY_MODE
/* the next assertion is probably not really needed */
cta(ari_is_4_char, sizeof(mksh_ari_t) == 4);
/* but this is */
cta(ari_has_31_bit, 0 < (mksh_ari_t)(((((mksh_ari_t)1 << 15) << 15) - 1) * 2 + 1));
/* the next assertion is probably not really needed */
cta(uari_is_4_char, sizeof(mksh_uari_t) == 4);
/* but the next three are; we REQUIRE unsigned integer wraparound */
cta(uari_has_31_bit, 0 < (mksh_uari_t)(((((mksh_uari_t)1 << 15) << 15) - 1) * 2 + 1));
cta(uari_has_32_bit, 0 < (mksh_uari_t)(((((mksh_uari_t)1 << 15) << 15) - 1) * 4 + 3));
cta(uari_wrap_32_bit,
    (mksh_uari_t)(((((mksh_uari_t)1 << 15) << 15) - 1) * 4 + 3) >
    (mksh_uari_t)(((((mksh_uari_t)1 << 15) << 15) - 1) * 4 + 4));
#endif

This means that either
– mksh_ari_t (typedef’d to int32_t which is most likely typedef’d
  to “signed int”) is not 4 c

Re: mksh and plan9

Thorsten Glaser — 2013-06-18T18:24:40

Jens Staal dixit:


Indeed. It’s, of course, a bit tricky to actually detect it.


That’s true for *all* of them ;-)

One of the conditions (“cta” in the source) is untrue.


Please resend as unidiff (“diff -up” or, if -p doesn’t work in your
diff(1) utility, at least “diff -u”).


We’ll see ;-) but first I need to have a legible patch ☻


That’s probably a good idea.


Their semantics (under Unix) differ. If Plan 9 does not distinguish
between a real uid/gid and an effective uid/gid, -DMKSH__NO_SETEUGID
like BeOS does.


Aieee. There we seem to have a reason…


We do need the APE cc front-end, not the native kencc, because
we do require an ANSI C præprocessor. But that’s nomenclature.


That’s known: add -DMKSH_NOPROSPECTOFWORK to get something that
closely resembles a working mksh, *but* lacks some fundamental
functionality and *will* hang some of the regression tests (those
marked “nojsig”).

In Haiku, the same problem existed but was confirmed to be a
kernel bug; see th

Re: mksh and plan9

Jens Staal — 2013-06-18T05:20:49

Apparently, by passing -L to Build.sh, ape/cc can build without a 
workaround. Does this mean that I should try to put in a test for 
"unknown" compiler on Plan9 early in the script and trigger "legacy"?

The gcc port on Plan9 can build without any modifications to Build.sh 
(except the re-definitions for seteuid and setegid).

Re: mksh and plan9 (was: watcom)

Jens Staal — 2013-06-17T12:17:26

In the attached patch, I do work around it since I don't understand the 
stuff. I am an amateur so much of what I do is horrible :)

There is most likely a much nicer solution to this problem.


Attached is a patch to Build.sh. I put the tests for "PLAN9" last in the 
compiler tests in the hope that (gcc and hypothetical) alternative 
compilers on Plan9 then would have a chance first.
I had to re-define setegid and seteuid to setuid and setgid - a problem?

With the attached patch (done with the Plan9 "diff -n"), mksh builds 
with the native "cc" compiler under Plan9 APE using Build.sh.

The resulting binary can execute and within the shell, one can execute 
an external command (I tried "lc") once but it does not go back to being 
ready for a new command (I tried killing "lc" with the Del key or ctrl-c).

Re: mksh and watcom

Thorsten Glaser — 2013-06-17T09:21:33

Jens Staal dixit:


You can export stuff like HAVE_CAN_OTWO=0 before running Build.sh
or put that into the Plan9) case.


Which of them precisely (there should be one above those)?
Working around the assertions is, unfortunately, not permitted.


Sure.

bye,
//mirabilos

Re: mksh and watcom

Jens Staal — 2013-06-17T07:23:05


This log looks very similar to what I get (except that I had to suppress 
a complaint about pwd.h).

BTW (off topic):
Since I started looking at mksh Build.sh again I decided to try to get 
it to run nicely under Plan9/APE. My previous builds were always with a 
custom mkfile, but I thought it would be nice to get it running "out of 
the box" (more future-proof that way).

I picked up 2 problems immediately, which was that ape/cc does not 
understand -O2 and -W... stuff. Because of this I will add a small test 
under compiler "unknown" to set ct=plan9 if that is the TARGET_OS and 
then add that one to the "do nothing" variant when it comes to add -O 
and -W flags (that way, if one runs the build under Plan9 with the gcc 
port, one should still be able to use fancy options).

For some strange reason ape/cc also chokes on this:

char ctasserts_dblcheck[sizeof(struct ctasserts) == NUM ? 1 : -1];
int main(void) { return (sizeof(ctasserts_dblcheck)); }


When I got it sorted out I will send a patch to the list

Re: mksh and watcom

Thorsten Glaser — 2013-06-16T15:37:19

Dixi quod…


You might want to read this too:

00:17 < RT|Chatzilla> just played a bit of openwatcom for linux, including /usr/include will cause other errors.
00:17 < lynx> yes, glibc doesn't play well with non-gcc
00:17 < lynx> that'd probably work with only very few exceptions (stdarg.h, etc.) on bsd
00:24 < RT|Chatzilla> I hacked owcc's types.h giving system-libc's defines, and got logs:
                      http://roy.dnsd.me/build-linux-owcc.log
00:29 < RT|Chatzilla> the one I most noticed is owcc has its own vi
00:38 < lynx> haha its own vi…

bye,
//mirabilos

Re: mksh and watcom

Thorsten Glaser — 2013-06-15T16:07:44

Jens Staal dixit:


.oO(why bash? ☺)


The http://www.debian.org/doc/manuals/maint-guide/ is pretty
useful, although packaging mksh for Debian initially took me
two whole days (compared to two hours or so for pkgsrc® and
another two hours for “everything else”).


Interesting. I attended a related talk at FOSDEM…


So true.

bye,
//mirabilos

Re: mksh and watcom

Jens Staal — 2013-06-15T08:13:11

I just found a set of scripts that may help in building the github 
"version 2" sources.

https://bitbucket.org/GregorR/openwatcom/wiki/Home

I was especially interested thanks to the two custom "ar" and "ranlib" 
bash scripts installed in "binl".

If I manage to combine the two I will let you know and send the URL to 
my Arch PKGBUILD (pretty easy to follow and to adapt).

I have tried learning other Linux packaging formats and have sort of 
figured out the rpm:s, but still struggling with .deb:s (packaging the 
NetBSD Rump kernel on OpenSuse Build service for most Linux distros).


Thanks! Always fun to try something new :)

Re: mksh and watcom

Thorsten Glaser — 2013-06-14T21:35:48

Jens Staal dixit:


OK, will do. You’ll find that “the mksh crowd” actually lives on such
“fringe” things. There are Plan 9 people, Minix (pre-Minix3) people,
suckless.org people, Haiku, Syllable, Hurd, OSF/1, ULTRIX, and lots
more here.


Hm, interesting.


I’ll have a look at it (and will peek at getting it to work on BSD).


Typical… ;-)


The compiler driver should behave cc-like enough, yes.
I think we noted that $somewhere, but once you got a
bit farther I can really put it on the homepage.


Off-topic, but you may put a follow-up posting to this one
to the mailing list (with a subject change, and do a separate
follow-up without the subject change for continuing the mksh
discussion, please), in case someone’s got an idea – IRC is
also usually a good bet.


So <pwd.h> should be made optional? That’s not a problem.

[…]

Okay, you definitely need sigsetjmp() which pulls in sigjmp_buf
(if and precisely if your _setjmp() or setjmp() has sigsetjmp()-like
behaviour, we can get along wit

Re: mksh and watcom

Jens Staal — 2013-06-14T21:05:49

Hi

sure you can do that. I just thought this to be a bit too "fringe" to 
actually be of general interest.


The official version is handled by perfoce, which is somewhat annoying, 
but source tarballs are available along with x86/x86_64 Linux binaries.

http://www.openwatcom.org/index.php/Downloads

There is also a github mirror/fork
https://github.com/open-watcom

but I failed building that one...



I will if I figure it out... basically trial-and-error stuff at the 
moment. Just realized that setting CC=owcc instead of CC=wc386 makes a 
lot of the tests work.

The only way I found that was thanks to stored e-mail stuff found via 
google related to using gmake Makefiles instead of wmake ones. 
Documentation is definitely scarse.

Stuff I do need to try to figure out is whether I need to
define some other stuff like AR, RANLIB or similar (I also played with 
trying to build suckless.org sbase (aiming for small stuff with no 
external dependencies) and got as far as the "util.a" library but could 
not lin

mksh and watcom

Jens Staal — 2013-06-14T14:46:50

I just recently discovered tests for watcom in the Build.sh script

Naturally curious as I am, I started to play with trying to compile mksh 
with openwatcom on Linux (Arch x86_64) - mostly due to nostalgia with 
all the Dos4GW games etc... curious to see how small/performant 
openwatcom can make a real modern program compared to GCC.

It seems like the tests choke on a number of places (preprocessor does 
not successfully identify watcom etc...). and the libc bundled with 
openwatcom does not contain some headers that seems to be needed.

Are there any tricks to get through the Build.sh? Or is the watcom 
support abandoned? There seems to be a lot of warnings during the tests...

For reference, I attach my modified PKGBUILD (modified from the 
officially distributed variant of mksh in Arch linux) that I use for my 
compilation tests.
# $Id$
# Mantainer: Jens Staal <staal1978< at >gmail.com>
# adopted from the community build:
## Maintainer: Thorsten TC6pper <atsutane-tu< at >freethoughts.de>
## Contributor: Daniel Ho

Re: mksh and watcom

Thorsten Glaser — 2013-06-14T19:06:06

Hi,

instead of sending this to me I’d love to have such discussions
in public, on the miros-mksh< at > list – if you give your Okay, I’ll
bounce those mails there and will follow up in public.


Jens Staal dixit:


Oh, Watcom now exists for Linux? Do you have any further information
on that (does it come with source; is it even Open Source; does it
exist in Debian, is it portable to MirBSD, what (CPU) architectures
are supported)?


Feel free to suggest fixes for that ;-)


mksh does need a somewhat Unix environment. If you can share what
headers are missing… as long as the functionality is there, I can
make them optional and/or include/check for different headers.

fork() is an absolute requirement however, so a DOS-like environment
including djgpp (I tried! But bash.exe segfaulted trying to run
Build.sh…) is not enough.


Depends mostly on the place. Header checks are easy, others, not so.


There’s none… it was, according to the changelog, submitted by RT
from IRC, but only “begun”. I do not

Re: disproved Non-compliance of \c for echo and print builtins

Steffen "Daode" Nurpmeso — 2013-06-07T19:54:40

 |Steffen Daode Nurpmeso dixit:
 |
 |>But, according to the famous (to me) [1], mksh-R28/R39 did support
 |>\c, which made me thought it's also working like \c is supposed to
 |>work.
 |
 |No. \c is *not* supposed to work in POSIX mode.
 |The implementations̲ (note the plural form) of
 |the echo builtin got fixed in the meantime.
 |
 |You can select between them, though.
 |
 |tglase< at >tglase:~ $ mksh -c 'echo foo\\c; echo $KSH_VERSION'
 |foo< at >(#)MIRBSD KSH R46 2013/05/02

You mean

  0[steffen< at >sherwood nail.git]$ dash -c 'echo foo\\cwooh!; echo $HOME'                                                                            
  /Users/steffen

 |Try set +o posix +o sh.

  0[steffen< at >sherwood nail.git]$ mksh -c 'echo foo\\cwooh!; echo $HOME'                                                                            
  foowooh!/Users/steffen
  ?0[steffen< at >sherwood nail.git]$ mksh -o posix -o sh -c 'echo foo\\cwooh!; echo $HOME'                                                             
  foo\cwooh!
  /Users/ste

Re: disproved Non-compliance of \c for echo and print builtins

Thorsten Glaser — 2013-06-07T18:41:11

Steffen Daode Nurpmeso dixit:


No. \c is *not* supposed to work in POSIX mode.
The implementations̲ (note the plural form) of
the echo builtin got fixed in the meantime.

You can select between them, though.

tglase< at >tglase:~ $ mksh -c 'echo foo\\c; echo $KSH_VERSION'
foo< at >(#)MIRBSD KSH R46 2013/05/02

Try set +o posix +o sh.


In that case, use print ;-)

bye,
//mirabilos

Re: disproved Non-compliance of \c for echo and print builtins

Steffen "Daode" Nurpmeso — 2013-06-07T18:22:53

 |Steffen Daode Nurpmeso dixit:
 |
 |>I'm fine with using printf(1), which is the one that works the
 |>expected -- but for this one mksh.1 (but this is R45) says that
 |
 |>  have added this as builtin as a speed hack.  Do not use in new
 |>  code.
 |
 |Yes, it turns out printf(1) is massively less portable:
 |its amount of functionality differs greatly, and it’s
 |not even available on all OSes that were current in the
 |mid-2000s decade.

You know, we turn in circles here.
But, according to the famous (to me) [1], mksh-R28/R39 did support
\c, which made me thought it's also working like \c is supposed to
work.

 |If you are allowed to limit script execution to Korn Shell
 |(this includes ksh88, ksh93 and dtksh, pdksh, mksh, MKS ksh)
 |use print (whose -n option prevents newline printing, and
 |whose -r option prevents backslash interpretation) with
 |a -- as argument separator.

It's all private around here, so no problem.
I'm using echo(1) if there's nothing special and printf(1) if
there is (because i

Re: disproved Non-compliance of \c for echo and print builtins

Thorsten Glaser — 2013-06-07T16:05:22

Steffen Daode Nurpmeso dixit:



Yes, it turns out printf(1) is massively less portable:
its amount of functionality differs greatly, and it’s
not even available on all OSes that were current in the
mid-2000s decade.

If you are allowed to limit script execution to Korn Shell
(this includes ksh88, ksh93 and dtksh, pdksh, mksh, MKS ksh)
use print (whose -n option prevents newline printing, and
whose -r option prevents backslash interpretation) with
a -- as argument separator.

Really.

bye,
//mirabilos