[dev] Re: tabs
Michael Hauser dixit: >the convenience would be that I don't need to memorize 2 separate ways >of handling windows. As tabs are really just another way of presenting >windows. I’m using “nested” tabs a lot. For example, on the 12″ laptop I’m typing this eMail right now, this is a pine session on a server, on which I’m connected per ssh using a shell in a GNU screen inside xterm. Occasionally, I even have a GNU screen running remotely. (Didn’t switch to tmix yet as it doesn’t handle all my usecases, and I have heavy local patches to GNU screen.) The xterm is almost-fullscreen here, but some people have lots of them, and I occasionally do. This all runs on X11, with evilwm, which provides 8 virtual workspaces, which I also use heavily (at least 2, usually 3, often 4, sometimes more). I’ve gone far enough to assign memorised positions to usecases and/or applications, e.g. IRC is on GNU screen tab #0 on xterm on virtual desktop 1, mail is tab#1, music and “leisure reading” lynx session are in screen tabs on virtual desktop 2, etc. bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] Announcing sinit - the suckless init
Sylvain BERTRAND dixit: >Just to let you know, I have a little initramfs project. The init >process is hardcoded directly on the linux syscalls. On Linux, syscall numbers, argument number, order and size, etc. differ by architecture. bye, //mirabilos -- Ach, mach doch was du willst, du hast doch eh immer Recht! jupp ~/.etc/sig……… unfaßbar… Mit Eszett sogar, unfaßbar!
[dev] Re: Reasonable Makefiles
“Re: *** GMX Spamverdacht *** [dev] Reasonable Makefiles”.
Honestly!
Markus Wichmann dixit:
>A typical Makefile of mine looks like this:
Ugh, a horrid GNUmakefile… I normally write:
PROG= foo
.include
Or, if the sources are more than just foo.c, and if the manpage
is in section 8:
PROG= foo
SRCS+= foo.c
SRCS+= bar.c
SRCS+= baz.c
MAN=foo.8
.include
Of course, I could also write…
SRCS!= cd ${.CURDIR} && echo *.c
… but I prefer explicit enumeration here. (We do have implicit
enumeration for some cases, like ports subdirs, and manpages in
the manpage-only source subdirs.)
bye,
//mirabilos
--
Ach, mach doch was du willst, du hast doch eh immer Recht!
jupp ~/.etc/sig………
unfaßbar…
Mit Eszett sogar, unfaßbar!
Re: [dev] Announcing sinit - the suckless init
Eckehard Berns dixit: >I actually use ctrl-alt-del and alt-up from time to time :) But I could >live without it. Hmm, I actually forgot. Do the BSDs handle ctrl-alt-del >in any way on x86? Yes. Not just on x86. It sends SIGUSR1 to pid 1. 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: [dev] Announcing sinit - the suckless init
Eckehard Berns dixit: >Also, would it be worth it to deal with x86 Linux's ctrl-alt-del? It would >pull in OS specific code, and maybe people don't care for ctrl-alt-del >on the console, since everybody lives in X anyway. Hm, isn’t Ctrl-Alt-Backspace+Ctrl-Alt-Del (when not using xdm) or Ctrl-Alt-F1+Ctrl-Alt-Del the normal way to shutdown a system? bye, //mirabilos -- Ach, mach doch was du willst, du hast doch eh immer Recht! jupp ~/.etc/sig……… unfaßbar… Mit Eszett sogar, unfaßbar!
Re: [dev] ncurses or ...
Lee Fallat dixit:
>editor. I think some can guess where I'm coming from...
Message-ID:
^^
Not hard to guess. Go die. Elsewhere. And quiet.
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: [dev] Mailinglists
Alexander Huemer dixit:
>> What client do you use for newsgroups?
[…]
>I totally agree. Most Client applications for NNTP suck. Somebody^{(tm)}
>should write a better alternative.
pine rocks, IMHO. My problem is rather that I’ve got no access² to a
working “regular” usenet server any more, only GMane’s which is only
a gateway to their mail archive.
>> I like the protocol, though.
>
>After reading [1] I really wonder why MLs became so popular. I believe
>the problem of the usenet are the binary usegroups which became popular
>for warez and are now reduced to that in the view of the general public.
And ISPs, which is the reason for ②. The “ncnntp” server mentioned in
the below script is not usable much any more either. Also, hold times
on whatever Usenet servers I saw in the last five years or so are way
too low.
begin 755 getarticle
M(R$O8FEN+VUK'`@)`HC+0HC
M($-O<'ER:6=H="#"J2`R,#$R"B,)5&AO2P*(R!M97)G92P@9VEV92!A=V%Y+"!O2!K:6YD+"!T;PHC('1H92!U
M=&UO2!A<'!L:6-A8FQE(&QA=RP@;F5I
M=&AE'!R97-S(&YO<@HC(&EM<&QI960[('=I=&AO=70@;6%L:6-I;W5S
M(&EN=&5N="!O2!A(&QI8V5N"!F;W)M870@;6%I;"!F;VQD97(@=V4@87!P96YD('1O
M"@IN,"TY72]D)R`M92`G+UY<+B0O+"1D
M)R!\(%P*("`@("AD871E("UU("LG1G)O;2!-04E,15(M1$%%34].("5A("5B
B("5E("5(.B5-.B53("59)SL@8V%T*2`^/GXO;6%I;"]X"@``
`
end
bye,
//mirabilos
--
Warum ist MirWebseite eigentlich so cool? weil ich
ich sie geschrieben habe Hast du sie geschrieben oder geforkt?
geschrieben, from scratch Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.
[dev] Re: 8-bit transparency in the C locale vs. UTF-8 support
Rich Felker dixit: >> >Wouldn't a 16-bit wchar_t be non-standard-conform when using a UTF-8 >> >locale? >> >> Nope. UTF-8 is just an encoding for Unicode, and as long as I take >> care to #define __STDC_ISO_10646__ 29L (and no later date) this >> is perfectly permissible. >This is only a possibility for implementations which only support the >BMP (Basic Multilingual Plane, aka plane 0, of Unicode, covering >Unicode Scalar Values in the range 0 to 65535). Yes, exactly. That was my goal when choosing this. (But, as I said, my suggestion wrt. handling of the encoding is not limited to 16 bit; it’s perfectly possible to handle full 21-bit Unicode/ISO-10646 with it, just my code was only written to support 16-bit BMP.) >It's fundamentally impossible in the C language to support UTF-8 with >the full Unicode range as a locale's multibyte encoding when wchar_t >is 16-bit ACK. No complaints there. This is outside of the scope of MirBSD. I will not use UTF-16 there, either. >"support" the full Unicode range using UTF-16 for wchar_t and CESU-8 >for the multibyte encoding Yikes, no! >> This just means that your C locale cannot be strictly UTF-8. All >> others can, but the C locale is precisely for this. This is because >> the C locale is special like that. > >It's not special like that in any current or past issue of the >standard, but the proposal here is to change it so it is special like >that. I object to this change. It’s not explicit yet, but ⓐ implied already (otherwise they would not announce it like that, and IMHO it’s a non-change) and ⓑ common current and expected behaviour, and, as such, sensible to require. Plus, I showed you how it can be done. 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: 8-bit transparency in the C locale vs. UTF-8 support
Silvan Jegen dixit: >Wouldn't a 16-bit wchar_t be non-standard-conform when using a UTF-8 >locale? Nope. UTF-8 is just an encoding for Unicode, and as long as I take care to #define __STDC_ISO_10646__ 29L (and no later date) this is perfectly permissible. (And please do not language-lawyer me, I’ve had enough of those, and since I can prove that 100% POSIX compliance is probably illegal in my country, I don’t care, even.) >So the problem seems to be that binary files contain bytes that are not >valid UTF-8 and that using tools on them that expect UTF-8 will mangle >these files. No. The problem is that “using tools that use the wchar_t API” will mangle them _iff_ the locale is UTF-8. So if your C locale is UTF-8, you *will* break all kinds of things, since “env LC_ALL=C tr x x
8-bit transparency in the C locale vs. UTF-8 support (was Re: [dev] [sbase][RFC] Add a simplistic version of tr)
Strake dixit:
>Use wchar.h functions and a sane libc, e.g. musl, which has a pure
>UTF-8 C locale, which ISO C explicitly allows [1].
>
>The 8-bit clarity what POSIX wants [1] seems nonsense to me, as one
>can use byte functions for that, but I may be wrong.
^^
Not always, see below.
>[1] http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc
MirBSD has exactly one “locale” (just enough to satisfy POSIX),
and it’s pure UTF-8 (with a 16-bit wchar_t though) but 8-bit clean.
This was a requirement from the start.
Imagine this: txtfile and binfile are, respectively, a plain text
UTF-8 file and a binary file (say, an ELF object). “with*locale”
is a placeholder to set the respective LC_* settings or something.
$ withClocale tr x x txtfile2
$ withUTF8locale tr x x txtfile3
$ withClocale tr x x binfile2
$ withUTF8locale tr x x binfile3
The output of this, when using a character-aware tr(1), will be:
• txtfile2 and txtfile3 will be identical to txtfile
• binfile2 will be identical to binfile
• binfile3 will be 0 bytes long, and the system will
have thrown EILSEQ, because the binary file contains
sequences that are not conforming UTF-8; this is actually
*required* and *correct* and the reason Debian has introduced
(on my prodding) a “C.UTF-8” locale, which is just the same
as “C” except with UTF-8 encoding, and _always_ installed.
Now, on a system with multiple locales, you can just set the
appropriate locale when dealing with files you know are binary
or UTF-8 text. If you know.
But if your “C” locale is UTF-8, you absolutely lose the ability
to operate the standard Unix utilities on nōn-UTF-8 files (or,
for example, files with mixed encoding). Hilarity ensues (such
as nvi in Debian trashing files *on save*, with no warning before
and no method to revert) with such files in UTF-8 encodings.
You cannot just “use the byte functions” because, for example,
you want to use tr(1), or you want to use your favourite editor
on a file that’s “mostly” UTF-8 but contains some “raw octets”;
the script I use in MirBSD to convert catmanpages to HTML is
such an example because these octets (e.g. \xFE and \xFF) are
used as separators for sed(1) calls, or placeholders.
I hope to have sufficiently shown my case.
Now, as for the solution, as first appeared in MirBSD:
I have invented a scheme whereas, upon conversion between 8-bit
(multibyte) and (in MirBSD) 16-bit (wide) character{s, strings},
every input that is not well-formed UTF-8 (e.g. \xC2 \x80, \xFF)
is mapped into a 128-codepoint range in the Private Use Area,
and upon conversion back to multibyte, mapped back appropriately.
Well-formed UTF-8 on the multibyte side that corresponds to one
of these 128 codepoints is *also* taken as invalid in order to
guarantee round-tripping; one should not have been storing PUA
characters in files in the first place *and* expect to be able
to manipulate them on every OS too. (Just round-tripping works,
but e.g. tr $'\uEF80' $'\uEF81' will not work.)
I’ve tentatively assigned a 128-codepoint PUA range for this,
but then contacted the ConScript Unicode Registry which is a
voluntary agreement to reserve each others’ ranges, and asked
for a 128-codepoint assignment there (and got one, and also
registered some other PUA users from Linux and Apple with them).
MirBSD now maps \x80 to (wchar_t)0xEF80, \x81 to (wchar_t)0xEF81,
etc. up to \xFF to (wchar_t)0xEFFF, when converting from multibyte
to wide characters; additionally, the octet sequences ranging from
\xEE\xBE\x80 to \xEE\xBF\xBF which are (strictly spoken) valid UTF-8
are mapped to L"\uEFEE\uEFBE\uEF80" - L"\uEFEE\uEFBF\uEFBF".
Python 3 later had the same problem, and solved it in the same way,
although using a different range. Their system uses “Unicode” strings
throughoutly, which is fancy for wchar_t strings (and probably more
portable than the C equivalent), but one needs to be able to, for
example, call the open(2) equivalent with arbitrary 8-bit filenames
(as POSIX filenames are octet strings except NUL and slash). Their
mapping is defined in PEP 383, and instead of using the PUA they
map to the “second” half of UTF-16 surrogates, arguïng that surrogates
never occur unpaired in valid Unicode sequences. (I disagreed because
this makes the encoding stateful again, which was one major benefit
of Unicode to not have. Martin decided to not switch to the MirBSD
PUA mapping; we agreed to disagree there. Additionally, at the current
point in time, MirBSD is still (deliberately – to keep the implemen‐
tation small and suckless) “confined” to Unicode BMP, i.e. does n̲o̲t̲
use UTF-16 anyway, so we could not use their definition.)
The implementation mostly consists of one macro, two files, and
a type definition (which is inspired by Bruno Haible’s libutf8):
#define iswoctet(wc)(((wchar_t)(wc) & 0xFF80) == 0xEF80)
https://www.mirbsd.org/cvs.cgi/src/kern/c/optu8to16.c?rev=HEAD
https://www.mirbsd.org/cvs.cgi/src/kern/c/optu16to8.c?rev=HEA
Re: [dev] strlcpy and strlcat
Daniel Bryan dixit: >I'd like to know what the opinion here is of these functions. I've so Not using them in this time and age is gross negligence. Using strcpy, strcat and sprintf is even more; using strncpy is minor negligence, but _strncat_ is positively dangerous. So, yes, by all means, use strlcpy, strlcat, snprintf. (On strcpy_s: these were implemented in, IIRC, MSVCRT before, but nobody bothered with them. Instead, I noticed Win32 developers adding strlcpy too. Funnily enough, strcpy_s mostly behaves like strlcpy except its return value is less generic.) 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: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Bobby Powers dixit: >I'm surprised no one has mentioned the Plan 9 C compiler. There seems Hm, does it support something other than ECOFF output now? The assembler part is also very foreign… I’ve also got one more: nwcc (Nils Weller’s C compiler). bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc.
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Paul Onyschuk dixit: >(those can be copied from Heirloom or from older version of Groff - Or my version from AT&T nroff, which got bugfixes in the else-part of GNU groff specifics. I’ve got them in CVS as src/share/tmac/ (not /usr/lib/ but /usr/share/ as per the standard modern-BSD filesystem hierarchy). >macros itself are BSD licenses AFAIK, just macros from newer version >expect a support for arbitrary number of macro arguments). There is Yeah, you don’t get that with AT&T nroff either. And the amount of NetBSD® manpages where I had to fix things like \*[Lt] into \*(Lt is amazing. >[1] http://manpages.bsd.lv/history.html Hm, so this is the 1972 one. Maybe I should write what I did to the mdocml people to get added to that list. Thanks for the pointer! 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
Re: [dev] Optimizing C compiler & c++ compiler/runtime
(Wondering about the topic, no idea why one would want to use C++ anyway… but… *shrug*) Sylvain BERTRAND dixit: >> This is valid question on other hand e.g. base OpenBSD is C++ free for >> some time AFAIK (after the removal of groff). Idea of minimal set of Same for MirBSD (removal of GNU groff in 2004 or so). >> tools, capable of rebuilding itself is attractive. > >Oh! What openbsd uses for its man page terminal renderer? I'm >stuck with the buggy heirloom tools. Oh, they’re buggy? Damn. I had hoped for a ditroff implementation eventually. I’m using the AT&T nroff from 4.4BSD-Alpha in MirBSD, which are a full *roff implementation. The tbl cannot handle enough text diversions to format terminfo(5), but, with some tweaks, and lots of fixes to the UCB macropackages, everything else works pretty well. The code is far from suckless though: typical for its age, “let’s read everything into static buffers and hope for the best”, “int is a pointer”, no function prototypes, you name it. It builds with GCC 3.4.6 -O1 but not -Os or -O2. Fixes welcome (src/usr.bin/oldroff/ in CVS). I did use this on Interix (SFU 3.5), too. Note this is nroff/troff, i.e. console and line printers only, and troff is for that typesetter, only. (But the output, console, converted to HTML with my script for the MirBSD manpages, and even natively on an Epson FX-80 dot-matrix printer, is decent.) And it’s much slower than GNU groff on the same hardware (e.g. SPARCstation 5/170) on the same manual pages (especially -mdoc). I’ve got a tape archive from the original ditroff, which I cannot use because of legal issues (someone in the USA probably can take it as Public Domain). I did contact the ditroff author, but he could not help me, nor could Lucent. 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: [dev] wswsh: a mksh web framework
Paul Onyschuk dixit: >With mdocml [1] you get nice HTML output for free, because it Actually, no output at all, since it’s not a full *roff processor, and I (have to) use a compatibility leader (between AT&T nroff, GNU groff with UCB macros, and GNU groff with GNU macros) which also implements less portable macros like .Mx in my manpages. >On other hand you need stick to the mdoc/man and avoid low level >roff. This doesn’t work at all, e.g. the HYPHEN-MINUS is mangled in GNU output, leading to broken copy/paste behaviour. 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: [dev] wswsh: a mksh web framework
Chris Down dixit: >If masking files with directories is considered "clean", then I don't >want to live on this planet any more. >Just don't do it. Agreed. I don’t put *.htm files into subdirectories at all; the other MirWebseite setup does it as it’s got some more hierarchically structured content besides the main page. Actually, using “directories” is bad since it relies on the index.* files being called correctly, *and* because people are too stupid to append the extra slash at the end, leading to extra redirects (or error pages). Paul Onyschuk dixit: >concatenation and line breaking is too terse: two spaces at the end of >line - I don't consider that a good choice. Anything using whitespace as significant sucks. Anything using whitespace at end of line/file as significant is even worse, an abomination, and ought to be shot before birth, period. (And I so regularily remove whitespace at EOL left there by some vim user from my files that I made me an editor macro to do that.) >It is very easy to hit corner cases with Markdown. Example: code block That’s also one. This thing “looks easy” at first glance but is frustrating to someone used to something much better. >Few words on roff. I you stick to man, mdoc and ms macros and avoid ACK on mdoc, *definite* NAK on man, and no opinion on ms (since I do most “paper-ish” stuff in mdoc). >low-level roff stuff, it is quite nice format. On the first look it is Though I do low-level *roff stuff too. I had to learn it because I had to fix the mdoc macro _implementation_ itself… not too hard, the classical documentation https://www.mirbsd.org/manUSD/21.troff and https://www.mirbsd.org/manUSD/22.trofftut are nice intros. >quite alien, but it originated on Unix and that shows off. Sed, >awk, grep and other standard tools work great with sane roff >document: you can stick to the oneliners (I don't think that this can >be said about any other document format). Not always, there’s stuff that needs multilines in *roff, but with structural regexes that will work. Also, HTML output can be done (cf. the above links; those were done by AT&T nroff (from 4.4BSD-Alpha, hacked up) → col → some mksh script with lots of sed to convert them. Valid XHTML/1.1, or it’s a bug. Much nicer than GNU groff. No way to natively specify hyperlinks or other HTML features (due to this using the preformatted manpages that are generated during the BSD build anyway), and fixed-width output, but I chose to make it a feature and CSSify this to look like amber TTY output. 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: [dev] wswsh: a mksh web framework
YpN dixit: >I wrote a shell script using mksh, which generates websites. You need to write Just for completeness: I’ve written MirWebseite as a non-generic thing to generate static XHTML websites, too, and even got a second only slightly related installation (which, ofc, by now deviates quite a bit from the installation on the MirBSD/mksh website). Though, it needs the “CMS” user to provide valid XHTML/1.1 fragments; I absolutely d̲e̲t̲e̲s̲t̲ Markdown. And Natureshadow has written “SARAH” which is something similar, too. Turns out shell is not half bad at this kind of stuff ;-) So we have three exemplary “things” (I refuse to call my stuff a “framework”) in at least four installations, which people interested can have peeks at. bye, //mirabilos, wondering why t f anyone would want to do this in C which is obviously not TRT for string ops -- „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: [dev] Bringing together OS'es terminals and their codepages
Carlos Torres dixit: >here we go again... Sure… googlemail user ;) >should they ban people that use fortune in their signatures too? You’d be amazed to hear that I have a collection of individual sig files and select one manually when I don’t want to use the default one, which I rotate occasionally manually. ^Kr in jupp. bye, //mirabilos -- Ich gebs zu, jupp ist cool
Re: [dev] Bringing together OS'es terminals and their codepages
patrick295767 patrick295767 dixit: >I think about various possible POSIX and non-POSIX platforms, which >allow compiling with gcc or g++: You missed MirBSD, which incidentally is UTF-8 only (with the known issue that you need to run “script -lns” or GNU screen on the text console, but for Unicode you want xterm anyway). Troels Henriksen dixit: >patrick295767 patrick295767 writes: >> Let's take a well-known program: vim compiled for Windows. If you use >> gvim.exe in Windows, you have a perfect result. No simple problem with >> characters. >> However, if you take vim.exe (from the same directory as gvim.exe) and >> use it in the windows console (execute: cmd then type vim), you end up >That's because the standard Windows terminal is terrible. I would >advise never using it. Pretty much every other terminal in works >properly, because they don't try to simulate some ancient DOS >abomination. You’re right on the suggestion of not using it. (I read about PuTTY being suggested as replacement – does it allow a “local” shell? If so, it could even be used on Win32s which allowed 32-bit programs to run on Win3.1 but not console programs… hm…) But there are two ways to fix this for vim.exe: • chcp 65001 (switch the “codepage” to UTF-8, works horrible). • Change vim.exe to use the “wide” console instead of the ANSI/OEM console functions, which use proper UCS-2 (later UTF-16) characters for terminal I/O (works like a charm and even in NT 3.x). Christoph Lohmann dixit: >On Tue, 03 Dec 2013 18:53:04 +0100 Noah Birnel wrote: ^ >> On Tue, Dec 03, 2013 at 04:00:14PM +0100, Christoph Lohmann wrote: >> > Windows has to >> > adapt to Open Source and not the other way around. Right. Actually, they kinda did and are no longer among the biggest three offenders against OSS. >> Hahahahaha. >Please read up on software history. But maybe your poor Windows adminis‐ >trator life took away your sanity and sense for what’s possible. Please Or his Googlemail administrator. Or both… >leave suckless as fast as you can. I did suggest banning them, didn’t I? ☺ 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: [dev] [sbase][RFC] Add a simplistic version of tr
Silvan Jegen dixit: >That sounds reasonable but requires that we convert UTF-8 to UTF-32 >which should not be strictly necessary when we only map one UTF-8 value >to another. Arrgh, no. UTF-8 and UTF-32/UCS-4 are encodings of numerical Unicode codepoints. When working with text documents, you always operate on those codepoints. This was true for single-byte encodings as well, except there, the codepoints always fit into bytes. bye, //mirabilos -- 08:05⎜ mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ yeah. /bin/rm. ;) 08:09⎜ hexdump -C 08:31⎜ ft, mrud: *g*
Re: [dev] [sbase][RFC] Add a simplistic version of tr
Silvan Jegen dixit: >If I understand correctly you would use mmap to allocate a sparse >memory area into which we could then directly index (either using >UTF-8 or UTF-32 indices), right? Since mmap needs a file descriptor I think that wouldn’t help much. >Sadly, I do not follow. I recognize that the lengths of those arrays >multiplied correspond to the maximum number of Unicode code points >(1,114,112) but I am not sure how the mapping (from UTF-8 or UTF-32 >encoding) should be done. Care to enlighten me? Eh, &0xFF and >>8? 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: [dev] [sbase][RFC] Add a simplistic version of tr
Strake dixit:
>On 26/11/2013, Silvan Jegen wrote:
>> If you you would rather not take this version, what approach would
>> you take for the character set mapping when using UTF-8?
>
>On Linux, one can easily make a sparse array with 1-page granularity
>with mmap, and so simply use a (wchar_t []) or (Rune []), but I'm not
>sure how portable this is.
Pretty portable, and 2²¹ * sizeof(wchar_t)/CHAR_BITS is at best 2²⁵
or 32 MiB, so this would even work.
But common, for Unicode, is to use the planes.
struct {
wchar_t foo[0x100];
} *repl[0x1100];
Do note that sizeof(wchar_t) may be 16, and that the OS’ own
representation of wchar_t may not be Unicode, so the type would
be semantically wrong.
You might want to use uint32_t there.
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: [dev] [st] why is Glyph.fg, Glyph.bg long?
Roberto E. Vargas Caballero dixit: >On Wed, Nov 13, 2013 at 01:03:47PM +0000, Thorsten Glaser wrote: >> Roberto E. Vargas Caballero dixit: >> >> >long, because long is at least 32 bits for sure, but int can be only 16 >> >> On POSIX, int is a minimum 32 bit data type. > >I prefer follow the ISO rules about data sizes. That is stupid because this is a POSIX application and will not work without POSIX stuff anyway. >If you want 32 bits use uint32_t, in other case I will not apply the patch. The idea here is that “int” is faster than either “long” or “int32_t” – the former is for specific cases where int is not enough, and the latter will be forcibly 32-bit even if int is 64 bit on some machines where this is faster. You could use “int_fast32_t” if you’re so pedantic. But just using “int” here is probably the right thing to do. 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: [dev] [st] why is Glyph.fg, Glyph.bg long?
Roberto E. Vargas Caballero dixit: >long, because long is at least 32 bits for sure, but int can be only 16 On POSIX, int is a minimum 32 bit data type. 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: [dev] Mailing list behavior
hiro dixit:
>tldr
>
>On 11/6/13, Alexander Huemer wrote:
[…]
Can we please ban Googlemail from this mailing list?
(Funnily enough, recently I’ve started looking at From
headers more, and, sure enough, Googlemail users are
the biggest average idiots on other mailing lists as
well.)
bye,
//mirabilos
PS: “Hi” not always (not normally if I reply, only if I write
a fresh post), but “bye” is common.
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] IRC on Freenode
Chris Down dixit: >Gmail's web interface breaks nested quoting in plain text, unless they >fixed it recently. It pushes lines off the edge, and causes the quoting Oh ouch. I’ve not used it myself. >to screw up, so the whole thing is just better avoided. Indeed, this makes it even worse. Dmitrij D. Czarkoff dixit: >Thorsten Glaser said: >> (The frontend needs not be graphical, of course.) > >Why? Erm… because graphical stuff sucks? Because I run all my stuff in GNU screen (sure, in an uxterm, but that’s just to get the font and Unicode support with enough glyphs)? Because there’s precisely zero need for an IRC client to be graphical? Duh! bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] IRC on Free node
ludovic samek dixit: >encrypted actually? Do you know some dev lists where they use >encryption? I’m carrying the Secure List Server patch for mailman on the installations we use at work. (Reminds me to get the time to update and polish this and upload to Debian proper…) http://non-gnu.uvt.nl/mailman-pgp-smime/ It’s not perfect and a bit buggy, but it works, although I tested S/MIME only once, as we mostly use PGP. But I don’t think that this list uses Mailman 2… >> PS: My reason for avoiding OFTC is simply that the IRC client I use >> connects to only one IRC server at a time. > >Do you use also ii ? No, a highly patched sirc (somewhat sucky C frontend plus somewhat less sucky Perl backend), until such time as I actually write an IRC client in mksh. Oh, and sometimes, tinyirc which is pure C and just small. To be honest, I can’t stand using Plan 9 concepts like that in a Unix world. Not without a sort of frontend to be able to use it efficiently, anyway. (The frontend needs not be graphical, of course.) 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: [dev] IRC on Free node
Chris Down dixit: >On 2013-11-02 11:13, Dmitrij D. Czarkoff wrote: >> Gmail's webmail doesn't allow to tune quoting & attribution in a >> sensible manner, so repeating this every time doesn't make much sense. Meh, until it’s beaten into peoples’ brains… ;-) >Surely the answer to that is to not use Gmail's webmail client, then? Either that, or hand-trim the fullquote before adding one’s own text. People even do that in Outlook Expreß when they need to but know how to properly quote… it just involves a little bit of effort. But not much more, since one needs to trim the quote in other MUAs as well. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Re: [dev] IRC on Free node
patrick295767 patrick295767 dixit: >Security is not perfect. A bouncer is fine, or helps. You just want to flame, I’d guess. >The idea of protecting your data makes senses. Security is an >important topic. Says the Googlemail user. Oh, the irony. >2013/11/2 Ryan O�Hara : […] >> On 11/1/13, patrick295767 patrick295767 wrote: And neither the one nor the other Googlemail user know how to properly write eMails. I sense a theme there. DE: http://www.afaik.de/usenet/faq/zitieren/ EN: http://www.netmeister.org/news/learn2quote.html NL: http://www.briachons.org/art/quote/ >>> I may reply your question by another question, on the subject of plain >>> IP list, as follows: >>> - Do you like to be scanned, or bruted force, ...? […] Oh please. I’ve been on freenode two namechanges ago, NickServ says it’s been over 12 years, and it’s not happened to me, and I disbelieve in cloaks. (Though, using IPv6 surely helps ☺) bye, //mirabilos PS: My reason for avoiding OFTC is simply that the IRC client I use connects to only one IRC server at a time. -- 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
[OT] eMail (was Re: [dev] Some thoughts about XML)
koneu dixit: >Oh please tell me a good alternative free and reliable mail service. sendmail? postfix? There’s a lot of stuff around, and you can just run them for free on your own server. Easy to set up, too. (This is really stupid. Besides, you could just search around for unix shell accounts or related associations, such as trash.net or the SDF or gnook, who usually also offer SMTP. Yet, every self-respecting dev would rather host his eMail himself.) 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” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Re: [dev] Some thoughts about XML
hiro dixit:
>the format of ini files are a problem for you??
Multiple question marks, he said, are a sure sign of a diseased mind.
(Or something like that. It’s been some time since I last read him.)
>On 10/23/13, Thorsten Glaser wrote:
Oh great, TOFU! Please read and honour
http://www.afaik.de/usenet/faq/zitieren/
next time.
But what do I expect from a Googlemail user.
*sigh*
Why does suckless seem to collect so many clueless people?
bye,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] misc projects
Sylvain BERTRAND dixit: >> -Mdist normalises all uid:gid to 0:0 (and some other things that >Strange, I though this feature was available with basic CPIO utils. No, it’s not, it’s implementation-specific extension. But then, paxtar is a BSD-licenced and pretty compact implementation, so it shouldn’t be entirely unliked. bye, //mirabilos -- 21:49⎜ I have a question guys, ⎜Can I use my PC as SMTP server, I use Windows 7 . ⎜Already googled and Installed IIS ⎜but Still I can't send E-mail
Re: [dev] misc projects
Sylvain BERTRAND dixit: >and use CPIO text description to avoid being root to create the You can use paxmirabilis/MirCPIO for that (it’s packaged as “pax” in Debian wheezy and newer, in case you wonder). Example: find * | sort | paxcpio -oC512 -Hsv4cpio -Mdist | xz -2e >initrd -Mdist normalises all uid:gid to 0:0 (and some other things that make for better compression; use -Mnorm to also set all timestamps to the epoch, saves a few more bytes). bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. 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: [dev] Some thoughts about XML
Mihail Zenkov dixit: >It not mention good xml alternative: TOML Thank gods the time of Windows 3.x *.ini files is long gone. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. 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: [dev] Some thoughts about XML
Evan Buswell dixit:
>like you're gonna put UTF-8 parsing into cat.
cat is just a sendfile, it’s not doing anything with the content.
On the other hand, for a data exchange format, some measure of
data types is a commodity. JSON is not binary-safe, true, but the
Unix/Plan 9 way doesn’t need it to be.
>On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff
>wrote:
Oh and, for fucks sake, learn writing eMails!
Read http://www.afaik.de/usenet/faq/zitieren/ (this has links to
the English and Dutch version as well).
bye,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] Some thoughts about XML
Evan Buswell dixit: >playing with that adds symbolic references and uses binary instead of >utf-8 strings); RST is better for structured text---though I'm not Oh yeah, let’s all do binary now instead of passing around plaintext! Wait. No! Pointing out Unix/Plan 9 way works just fine, //mirabilos -- Beware of ritual lest you forget the meaning behind it. 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: [dev] Some thoughts about XML
Szymon Olewniczak dixit: >> s/HTML/XML+XSLT/g is quite a revolution. >But it's something whitch I can use in my application straight away >without forcing user to change their web browsers. But XSLT is a joke. Have you *seen* the lengths people go through to actually *do* anything in it? It may have seemed a good idea when Java™ was still “write once, run anywhere”… >It's about whole "modern web" stack and ways we can make it better, >without a huge revolution. Please read up on ROCA – http://roca-style.org/ – which I kinda like because it says your web “application” m̲u̲s̲t̲ work in Lynx, and any CSS and, possibly, ECMAscript may o̲n̲l̲y̲ be added in an unobtrusive way (e.g. to make things nicer, or to enable things like interactive statistic graphs that just don’t make any sense without, but n̲e̲v̲e̲r̲ to have any regular function of the application depend on it). It also uses REST, which means you get your share of the “modern web stack”. 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
Re: [dev] Some thoughts about XML
Chris Down dixit: >I don't even know what to say to this... Must be the full moon. First 20h “liking” kdbus, now this… bye, //mirabilos -- This space for rent.
Re: [dev] Some thoughts about XML
Szymon Olewniczak dixit: >Pages writen in XML has readable source No. Much like sendmail.cf, XML is a binary/object format and ought to be treated as such. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Re: [dev] [sbase] Command list
Truls Becken dixit: >bc dc bc can be done on top of dc; BSD does that (the dc uses OpenSSL for arbitrary-precision numbers). >killall I object, killall should never, ever, be used. (Try it on a Solaris system, for example.) >On 2013-10-18, at 12:29, sin wrote: >> make: Do we really need this in sbase? > >Make is a basic tool, useful in lots of situations. I’d call it a development tool, normally. >It would be nice not to rely on GNU for this. NetBSD make is portable (they use it for pkgsrc®). (MirBSD’s is, somewhat, but in a sucky way, and I’ve not had time to redo it since I learned a lot in the meantime; it was only a quick hack, never planned to persist, anyway.) >> sh: We agreed to do without a shell. > >Yes, and I agree for the user shell. It would still be nice to have a >minimalistic one for scripts, where extensions should be banned anyway. The problem is that all existing “minimalistic” ones suck. The posh approach (take pdksh and strip all extensions away) is interesting, but posh is very buggy, and the author said he’d base on mksh were he to restart now. But maintainance effort is hell on this (and you *will* accidentally remove things that are not extensions, and you *will* run into the problem that POSIX is, slowly, standardising most of them like $((…)) and $'…' now). That being said, mksh/lksh makes a nice /bin/sh for most systems… bye, //mirabilos -- This space for rent.
Re: [dev] [sbase] Command list
Alex Pilon dixit:
>I know the trick. I used base64 for that, not uuencode. Don't they
>both have the same overhead, other than uuencode's header?
Yes but uuencode is more portable… e.g. the Linux “base64” tool is
rarely installed anywhere and is extremely picky about the formatting
of its input; OpenBSD has b64decode but it demands header lines similar
to uuencode (MirBSD has b64decode -r which is not picky either – but
that’s only in MirBSD of course).
Nowadays, uuencode (“sharutils”) is not installed everywhere any more
by default, but it’s still the most widespread portable one and usually
easy to get if it’s not yet there.
Meh, maybe I should write a shell uu{en,de}code implementation and
put it into the standard .mkshrc I ship…
bye,
//mirabilos
--
This space for rent.
Re: [dev] [sbase] Command list
Alex Pilon dixit: >Don't od's and hexdump's functionality overlap? Yes, they (and hd) are normally one binary. >Do we still really need uuencode and uudecode? Yes! I often use them, in combination with GNU screen, to copy/paste files(!) from one tab to the other, when using other methods (such as rsync or scp/sftp) is unpractical or impossible (think serial console). bye, //mirabilos -- Boah, ich steck hier soviel Anstrengung ins Furzen, daß ich dabei Schwindelanfälle krieg
Re: [dev] [announce] Starch Linux is bootable and self-hosting
Strake dixit: >> “HTTP/1.1 200 Schön”?! > >What, is this improper usage? No, just funny. >Yes, sorry, I missed that it bound to IPv4 alone by default. Should >work now. Thanks. Nope – maybe it’s firewalled (looks like pf block drop)? tg@blau:~ $ nc -v6 starchlinux.org 80 nc: connect to starchlinux.org port 80 (tcp) failed: Operation timed out 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: [dev] [announce] Starch Linux is bootable and self-hosting
Strake dixit: >http://starchlinux.org/ “HTTP/1.1 200 Schön”?! One rather important thing: starchlinux.org has got an RR but the httpd does not listen on IP, only on Legacy IP. Please fix that, because otherwise, a good part of the ’net can’t ac‐ cess your site. 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: [dev] [sbase] [PATCH] ls: add option to reverse the sort order
Raphaël Proust dixit: >On Fri, Oct 4, 2013 at 2:32 PM, Alexander S. wrote: >> Uh, cannot this be achieved by piping output to tac? > >At which points someone asks why is there a sorted order at all in ls >output… cannot this be achieved by piping output to sort? Only if you pipe it through rs¹ afterwards. bye, //mirabilos ① https://www.mirbsd.org/man1/rs -- [ 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: [dev] OpenBSD terminfo
Roberto E. Vargas Caballero dixit: >This means that is needed be root to install a new definition, I was assuming you had control over the system, yes. >and it sounds strange to me that a normal user cannot add a >new terminal definition. There may or may not be a way, but I don’t know it. UTSL. 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…
[dev] OpenBSD terminfo (was Re: [st][PATCH] Wide character support)
Roberto E. Vargas Caballero dixit:
>After reading your reply I dig more in the problem, and I can see now
>that the problem is not related to the wide character patch. I am using
>OpenBSD now, where there is a binary database of terminfo definitions
>in /usr/share/misc/terminfo, and it has a very old definiton of st
Hm, at least it had one… I just added the definition from st git master
to MirBSD, FWIW.
>(I think 0.2). If I install a new system definition of st using tic,
>it stores the new definition in /usr/share/terminfo in a tree
Well don’t do that ☺
>indexed way like is usual, and if I install it for my user it stores
>it in ~/.terminfo like is usual to. But I don't know why it seems
>don't read the definitions in /usr/share/terminfo and ~/.terminfo,
That’s correct.
>and I am not be able of modify the default definiton.
Not able, or just unknowing?
$ cvs -qz9 -d :ext:anon...@anoncvs.fr.openbsd.org:/cvs \
co -PA -d foo src/share/termtypes
$ cd foo
$ ${EDITOR:-ed} termtypes.master
then insert a (new) st definition appropriately, save and quit
$ make BINDIR=/usr/share
$ sudo make BINDIR=/usr/share install
This updates the system-wide copies of both terminfo and
termcap databases, from the same master source.
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: [dev] [PATCH] Add -g (geometry) option to tabbed.
Christoph Lohmann dixit: >Thanks for the hint, but you didn’t do it right. The geometry string al‐ >lows to specify negative positions too and a negative zero too. Addi‐ Hrm, ok ☹ back to the drawing board, then (unless you’ve got a hint – I’ve not done any X11 programming previously). >tionally this now fixates the geometry of tabbed. I do not quite understand this? It sets a different geometry at start if one’s given, no change otherwise, AIUI. bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
[dev] [PATCH] Add -g (geometry) option to tabbed.
Signed-off-by: Thorsten Glaser
---
LICENSE | 1 +
tabbed.1 | 5 +
tabbed.c | 8
3 files changed, 14 insertions(+)
diff --git a/LICENSE b/LICENSE
index add8a53..b8dc9ea 100644
--- a/LICENSE
+++ b/LICENSE
@@ -3,6 +3,7 @@ MIT/X Consortium License
© 2009-2011 Enno Boland
© 2011 Connor Lane Smith
© 2012 Christoph Lohmann <2...@r-36.net>
+© 2013 Thorsten “mirabilos” Glaser
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
diff --git a/tabbed.1 b/tabbed.1
index d3ef06a..a315136 100644
--- a/tabbed.1
+++ b/tabbed.1
@@ -8,6 +8,8 @@ tabbed \- generic tabbed interface
.RB [ \-h ]
.RB [ \-s ]
.RB [ \-v ]
+.RB [ \-g
+.IR geometry ]
.RB [ \-n
.IR name ]
.RB [ \-p
@@ -34,6 +36,9 @@ detaches tabbed from the terminal and prints its XID to
stdout.
fill up tabbed again by spawning the provided command, when the last tab is
closed. Mutually exclusive with -c.
.TP
+.BI \-g " geometry"
+specifies the preferred size and position of the parent window.
+.TP
.B \-h
will print the usage of tabbed.
.TP
diff --git a/tabbed.c b/tabbed.c
index ba1df21..64dcd2a 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -160,6 +160,7 @@ static int (*xerrorxlib)(Display *, XErrorEvent *);
static char winid[64];
static char **cmd = NULL;
static char *wmname = "tabbed";
+static const char *geometry = NULL;
char *argv0;
@@ -890,6 +891,10 @@ setup(void) {
ww = 800;
wh = 600;
+ if (geometry)
+ XParseGeometry(geometry, &wx, &wy,
+ (unsigned *)&ww, (unsigned *)&wh);
+
dc.norm[ColBG] = getcolor(normbgcolor);
dc.norm[ColFG] = getcolor(normfgcolor);
dc.sel[ColBG] = getcolor(selbgcolor);
@@ -1125,6 +1130,9 @@ main(int argc, char *argv[]) {
case 'f':
fillagain = True;
break;
+ case 'g':
+ geometry = EARGF(usage());
+ break;
case 'n':
wmname = EARGF(usage());
break;
--
1.8.4.rc3
Re: [dev] [sbase] [patch] Fix warnings about strcpy() etc. on OpenBSD
sin dixit:
>On Thu, Aug 15, 2013 at 11:00:11AM +0000, Thorsten Glaser wrote:
>
>> >if(len+1 > *size && !(*p = realloc(*p, len+1)))
^
>> >eprintf("realloc:");
>> >
>> >- strcpy(&(*p)[len-n], buf);
>> >+ snprintf(&(*p)[len-n], n+1, "%s", buf);
>>
>> Again, I object… you do not calculate the length correctly.
>> Besides, this looks like a strlcat to me… if not, memcpy
>> might again be more wise; n+1 doesn’t match with len+1 from above.
>
>Will change these to memcpy(), thanks. However, I don't understand why n + 1
>is wrong here?
p is allocated with “len+1” bytes, so “len+1” should show up in
its size calculations… I admit (len+1-(len-n)) factors out as
n+1, but let the compiler do that was said recently AFAICT?
Anyway, this kind of offset magic is prone to produce buffer
over-/underflows later when other people touch the code.
Better be explicit: if you want a strcat, use strlcat.
>> Is not using spaces around operators normal for sbase, btw?
>> This is horrid. Please read https://www.mirbsd.org/man9/style
>> for something nicer-looking. (I used to do it wrong, too.)
>
>I always use spaces, however, the existing code I was changing was not
>using spaces.
Right – my comment on spaces was not a comment on your patch.
Sorry if that was unclear.
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: [dev] [sbase] [patch] Fix warnings about strcpy() etc. on OpenBSD
sin dixit:
> if(!(p = malloc(strlen(d->d_name)+1)))
> eprintf("malloc:");
>- strcpy(p, d->d_name);
>+ snprintf(p, strlen(d->d_name)+1, "%s", d->d_name);
I object. The better fix here is:
+ size_t sz;
- if(!(p = malloc(strlen(d->d_name)+1)))
+ if(!(p = malloc((sz = strlen(d->d_name)+1
+ memcpy(p, d->d_name, sz);
> if(len+1 > *size && !(*p = realloc(*p, len+1)))
> eprintf("realloc:");
>
>- strcpy(&(*p)[len-n], buf);
>+ snprintf(&(*p)[len-n], n+1, "%s", buf);
Again, I object… you do not calculate the length correctly.
Besides, this looks like a strlcat to me… if not, memcpy
might again be more wise; n+1 doesn’t match with len+1 from above.
> if(!(b->lines[b->nlines-1] = malloc(strlen(line)+1)))
> eprintf("malloc:");
>- strcpy(b->lines[b->nlines-1], line);
>+ snprintf(b->lines[b->nlines-1], strlen(line)+1, "%s", line);
snprintf invokes stdio… if the size is known, like in such
cases, use memcpy. And cache strlen(line) + 1 in a size_t.
Is not using spaces around operators normal for sbase, btw?
This is horrid. Please read https://www.mirbsd.org/man9/style
for something nicer-looking. (I used to do it wrong, too.)
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: [dev] Re: mksh build system
Anselm R Garbe dixit:
>Are you willing to accept a Makefile/config.mk approach for mksh? This
[…]
>My current approach for all sta.li userland tools is creating a custom
>Makefile/config.mk, simply because the existing Build.sh, autoconf or
>whatever approach sucks.
(jump to tl;dr at the end of the mail if needed)
I agree that they all suck. I know exactly why and where mksh’s
Build.sh sucks, but it’s the lesser evil for me (as upstream)
considering mksh’s target “market” (including really ancient
and really weird OSes).
The problem at hand is: upstream definitely needs the automatic
discovery of flags method because no downstream (not even distro
vendors) usually know exactly what to put in there.
One thing you *can* do with mksh, and which I regularily do for
MirBSD and Android, and which laffer1 regularily does for MidnightBSD,
is to have Build.sh generate you a Makefrag.inc that contains the
results from all the tests. You can then either include that from
a Makefile or (which is what we currently do) move the definitions
into the regular Makefile/Android.mk.
The CPPFLAGS you end up with are dependent on the OS, OS version
and mksh version, so you’d have to run this step once when you
import a newer mksh version. But it’s pretty decently automated,
so it’s not that hard.
As an example, running this
tg@hugh:~/build $ mksh /usr/src/bin/mksh/Build.sh -M
on MirBSD, after exporting CC and CFLAGS, yields:
-->8
# Makefile fragment for building mksh R47 2013/07/26
PROG= mksh
MAN=mksh.1
SRCS= lalloc.c eval.c exec.c expr.c funcs.c histrap.c jobs.c lex.c
main.c misc.c shf.c syn.c tree.c var.c edit.c strlcpy.c
SRCS_FP=/usr/src/bin/mksh/lalloc.c /usr/src/bin/mksh/eval.c
/usr/src/bin/mksh/exec.c /usr/src/bin/mksh/expr.c /usr/src/bin/mksh/funcs.c
/usr/src/bin/mksh/histrap.c /usr/src/bin/mksh/jobs.c /usr/src/bin/mksh/lex.c
/usr/src/bin/mksh/main.c /usr/src/bin/mksh/misc.c /usr/src/bin/mksh/shf.c
/usr/src/bin/mksh/syn.c /usr/src/bin/mksh/tree.c /usr/src/bin/mksh/var.c
/usr/src/bin/mksh/edit.c /usr/src/bin/mksh/strlcpy.c
OBJS_BP= lalloc.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o
main.o misc.o shf.o syn.o tree.o var.o edit.o strlcpy.o
INDSRCS=emacsfn.h sh.h sh_flags.h var_spec.h
NONSRCS_INST= dot.mkshrc $(MAN)
NONSRCS_NOINST= Build.sh Makefile Rebuild.sh check.pl check.t test.sh
CC= mgcc
CFLAGS= -O2 -pipe -std=gnu99 -Os -fweb -frename-registers -Wformat
-Wstrict-aliasing -Wbounded -fwrapv -fno-align-functions -fno-align-labels
-falign-loops=4 -falign-jumps=4 -march=i486 -mpush-args
-mpreferred-stack-boundary=2 -momit-leaf-frame-pointer -fhonour-copts
-Wno-deprecated-declarations -fno-asynchronous-unwind-tables
-fno-strict-aliasing -fstack-protector-all -Wall -fwrapv
CPPFLAGS= -I. -I'/usr/src/bin/mksh' -DMKSH_BUILDSH
-DHAVE_ATTRIBUTE_BOUNDED=1 -DHAVE_ATTRIBUTE_FORMAT=1
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1
-DHAVE_SYS_TIME_H=1 -DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1
-DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_MKDEV_H=0
-DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_RESOURCE_H=1
-DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SYSMACROS_H=0 -DHAVE_BSTRING_H=0
-DHAVE_GRP_H=1 -DHAVE_LIBGEN_H=1 -DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1
-DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=0
-DHAVE_VALUES_H=0 -DHAVE_CAN_INTTYPES=1 -DHAVE_CAN_UCBINTS=1
-DHAVE_CAN_INT8TYPE=1 -DHAVE_CAN_UCBINT8=1 -DHAVE_RLIM_T=1 -DHAVE_SIG_T=1
-DHAVE_SYS_ERRLIST=1 -DHAVE_SYS_SIGNAME=1 -DHAVE_SYS_SIGLIST=1 -DHAVE_FLOCK=1
-DHAVE_LOCK_FCNTL=1 -DHAVE_GETRUSAGE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=1
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=1 -DHAVE_NICE=1 -DHAVE_REVOKE=1
-DHAVE_SETLOCALE_CTYPE=1 -DHAVE_LANGINFO_CODESET=1 -DHAVE_SELECT=1
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_STRERROR=0 -DHAVE_STRSIGNAL=0
-DHAVE_STRLCPY=1 -DHAVE_FLOCK_DECL=1 -DHAVE_REVOKE_DECL=1
-DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1 -DHAVE_PERSISTENT_HISTORY=1
-DMKSH_BUILD_R=471
LDFLAGS=
LIBS=
# not BSD make only:
#VPATH= /usr/src/bin/mksh
#all: $(PROG)
#$(PROG): $(OBJS_BP)
# $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS_BP) $(LIBS)
#$(OBJS_BP): $(SRCS_FP) $(NONSRCS)
#.c.o:
# $(CC) $(CFLAGS) $(CPPFLAGS) -c $<
# for all make variants:
#REGRESS_FLAGS= -f
#regress:
# ./test.sh $(REGRESS_FLAGS)
check_categories= shell:legacy-no int:32
# for BSD make only:
#.PATH: /usr/src/bin/mksh
#.include
-->8
The only important line of this is the CPPFLAGS= one.
You’ll need from and including -DMKSH_BUILDSH up to
and including -DMKSH_BUILD_R={someversionnumber}.
As long as it’s one operating system, such as just sta.li,
the defines should stay the same – currently even across
varying CPU architectures.
As I use #if HAVE_FOO, defining the “
Re: [dev] Re: coreutils / moreutils - DC a directory counter
Bjartur Thorlacius dixit: > by the censor. In short, ext2/3 directories are linked lists. You can traverse Are they, still? I thought they had the equivalent of UFS_DIRHASH nowadays… 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
[dev] Re: daemon for DWM
Kai Hendry dixit: >And run your C program from systemd? (*duck*) /me shudders (at the mere thought of “anathema” Poettering software) Someone actually took my analog clock (written in mksh) and packaged it for Arsch Linux, with a systemd… whatever they call initscripts these days… that runs it on tty12. I’m still unsure what to think about that. bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] Re: coreutils / moreutils - DC a directory counter
Calvin Morrison dixit:
>Its called unionfs if I recall
No. Go read it again.
>On Jul 25, 2013 9:28 PM, "Thorsten Glaser" wrote:
And stop top-posting and full-quoting.
Read http://www.afaik.de/usenet/faq/zitieren/ (it’s in
German, English and Dutch, so no excuses).
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]
[dev] Re: coreutils / moreutils - DC a directory counter
Calvin Morrison dixit: >I was sick of ls | wc -l being so damned slow on large directories, so What, besides the printing and sorting, is the slow part anyway? Is it the VFS API or just the filesystem code? In the latter case… could workarounds exist? Someone asked this… http://fenski.pl/2013/07/looking-for-a-specific-fuse-based-filesystem/ … on Planet Debian this night. Something to think about. (No further input from me, besides mumbling that I had a vague idea of similar concept and wouldn’t be surprised if something like that already existed, and probably only in the Plan 9 world…) 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: [dev] [sbase] [patch] Optimize 'ls' and add '-U'
Chris Down dixit: >If you really care, any POSIX shell should be able to do this as long >as you don't hit ARG_MAX: > > set -- * && echo "$#" I think ARG_MAX may not be relevant here… but globbing * usually sorts, and shells don’t always use the fastest algorithms… … but OTOH, if you have that large directories, you have all sorts of other problems. “DDTT” and “KISS”, while not always available, are good suggestions ;-) 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: [dev] [st] Problem with shift insert in neo2 layout
Dixi quod… >What raw keys does it precisely produce in st? Oh wait. You expect it to insert from the buffer, as opposed to do a shell functionality. Meh. I just middle-click to do that. You might want to “xmodmap -pke” and look at the output, as well as toy around with xev. If you expect the shifted version to do the same as the unshifted one, you might need to patch the X keyboard definition. bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] [st] Problem with shift insert in neo2 layout
Markus Teich dixit: > I am using the neo2 keyboard layout [0] via "setxkbmap de neo" and noticed, > the > Shift+AltGr+ä combo does not work in st. > Can someone help me debug/fix this? What raw keys does it precisely produce in st? $ cat Then show what's written. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] [sbase] [patch] Adding tar v2
Nick dixit: >What other evil things can tar creators do? Symlinks with st_nlink ≠ 1 for one ☹ need to fix that in paxmirabilis (MirCPIO) too. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] [sbase] Patch to make md5 and sha1 more similar
Andreas Krennmair dixit: > from a few years ago that explains in detail how clever compilers really are > with their optimizations: http://www.fefe.de/source-code-optimization.pdf “Learn what the compiler does” – did anyone do that for pcc recently? I’m sure it does _not_ do all those uber-optimisations, and I believe that “it made sense last century but not now” is wrong for easy, low‐ hanging fruits like shifts and bitmasks (but that prematurely writing complex stuff that makes code illegible is still undesirable). bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc.
Re: [dev] [sbase] shell scripts
hiro dixit: >one more reason to use use proper plan9: bourne shell sucks a lot >compared to rc. Well nobody uses bourne shell (that thing with U+0060 for COMSUBs and ^ instead of | as pipe character) any more. Welcome to the 21ₛₜ century. Although I freely admit that POSIX shell also sucks and requires to fork’n’exec often. Just use Korn Shell. Any (modern) Korn Shell – i.e. mksh or the original AT&T ksh93. bye, //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: [dev] [sbase] Adding tar
Strake dixit: >miss them. Archiver/compressor integration loses, for it needs a flag >and code for each compression format. I’d not use those anyway. I normally compress with: find foo -type f | sort | cpio -oC512 -Hustar | gzip -n9 >foo.tgz Failing that, this one’s almost the same: tar -b 1 -cf - foo | gzip -n9 >foo.tgz The -z option is *not* the same. bye, //mirabilos -- ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • ↑ hab da „in function parselmouth“ gelesen ICH AUCH! • Ich hab gerade gedacht "Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o?" -- too much fanfic…
Re: [dev] [sbase] shell scripts
Strake dixit: >shift $(dc -e "$OPTIND 1 - p"); *what*?! shift $(($OPTIND-1)) is POSIX. bye, //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: [dev] [sbase] Adding tar
Markus Wichmann dixit: >One way I also find myself using quite often: > >tar xfC filename.tar.gz directory This one is, I believe, not portable: behind f the filename must be immediately. (Also you forgot z.) An often-seen case of this unportablity is people using 'tar xfz foo.tgz' instead of xzf, which is the one that works (almost) everywhere. >> For now, tar will not do compression. If sbase gains programs to do Just like Solaris ;-) bye, //mirabilos -- ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • ↑ hab da „in function parselmouth“ gelesen ICH AUCH! • Ich hab gerade gedacht "Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o?" -- too much fanfic…
Re: [dev] lisp
Andrew Gwozdziewycz dixit: >SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most Less portable: http://packages.debian.org/sid/sbcl#pdownload bye, //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: [dev] Re: Maintaining sbase
Chris Down dixit: >try mksh. FWIW, mksh has three different “echo”; if invoked as mksh, it uses a BSD echo by default which does interpret backslashes, but if one uses set -o posix (or invokes it as sh or -sh and it is compiled with -DMKSH_BINSHPOSIX (CVS HEAD)) it has an echo that only honours -n as first argument and doesn’t do anything else (Debian Policy §10.4). bye, //mirabilos -- [DJBDNS Zone] TTL 86400 – kann man da auch 1d schreiben? nö, außerdem kann ein Deutscher oder ein Japaner mit 1d ja erstmal nix anfangen, oder könntest du 1日 im zone file lesen? das heißt für mich: ein Regal, das u.U. schiefstehen könnte
Re: [dev] [sbase] built with watcom
Jens Staal dixit: > By the way: what is the status of MirOS on top of Linux? A dead project? It was never really worked on but apparently got hyped in “the media” (especially Wikipedia, which is known to get its facts wrong but disallow corrections). It was basically a “we could…” idea but not important enough. Although… we could, once both josef (my musl experiment) and mirₘᵢₙcⒺ work, base it on that. On the other hand, I had something planned to distinguish between GNU/Linux and MirLinux binaries using a PT_NOTE ELF section (maybe not actually needed especially if the kernel ABI is the same) and other things… we’ll see. I’m not familiar enough with current Linux (yet). bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] [sbase] built with watcom
Jens Staal dixit: > I am looking at Alpine at the moment... uclibc/busybox based That is precisely the thing I was *not* addressing by stating “company-use” ☺ Don’t get me wrong, I’ve started toying with something musl too, but for “at work” you don’t want that, or can’t justify it, or whatever. Also, you get to have lots of… not suckless stuff. GTK+ (GIMP, Inkscape, M*zilla Firebloat, at the very least), KDE (Kontact Enterprise/KDEPIM), and stuff like that. (I also dislike busybox and have reason to not trust µClibc. But I suppose if you put mksh on it, it’ll be at least usable ;) bye, //mirabilos -- I want one of these. They cost 720 € though… good they don’t have the HD hole, which indicates 3½″ floppies with double capacity… still. A tad too much, atm. ‣ http://www.floppytable.com/floppytable-images-1.html
Re: [dev] [sbase] built with watcom
Jens Staal dixit: >> How does someone use that package on a working Linux distribution? > That depends on how you define "working". Did nobody fork Arch from before it became poettering’d and UsrMove’d yet? May call it Hintern Linux ;-) Indeed, I see a serious problem should Debian also fall, because neither *buntu (for obvious reasons) nor Gentoo (for less obvious ones) are able to fill the “company use, but no need for sucky RHEL/SLES” niche… but it is still an if, and at least a GR away. bye, //mirabilos -- 17:57 < jtsn> Der 25C3 ist lustig. Deutsche Vortragende brechen sich vor deutschen Zuhörern auf Englisch einen ab. ;-) 18:01 < jtsn> Adolfs Werk war sehr nachhaltig. ;-)18:01 < jtsn> Das gab's nichtmal in der DDR, das Deutsche mit Deutschen auf Russisch reden. ;-) (10x cnuke@)
Re: [dev] [st] Enter unicode symbol
Thuban dixit: >But what about st? ^Au echo "bind u digraph 'U+'" >>~/.screenrc hf, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] (s)werc and the suckless.org homepage
Andrew Gwozdziewycz dixit:
>But how often does stuff actually get updated? You can simply pregenerate
>all the content and serve it... For a site with 50 pages, that's nothing.
FWIW, the MirBSD website is kept in CVS and generated with
some (BSD) make and mksh scripts, then rsync’d to a webserver
and its mirrors. I chose to not use post-commit hooks for that,
but it would certainly be possible.
(There are three CGIs in it that are just installed as-is, and
there’s a – let’s call it libgd frontend – that’s written in php
because, at that time, I couldn’t get libgd to work for me in C
directly, probably due to version difference, but I’m planning
to rewrite it in C once the new libgd version is stable; it’s
mostly used to produce png files that contain pre-rendered text
because we use a specific font for a “corporate” identity for
MirBSD (Gentium), and web font support is not very wide-spread
(maybe nowadays it is), so this is an entirely optional component.)
>On Tue, Jun 11, 2013 at 11:36 AM, hiro <23h...@gmail.com> wrote:
http://www.afaik.de/usenet/faq/zitieren/
And yes, this is *also* valid for eMail.
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: [dev] [sbase] 64-bit type for split
Galos, David dixit: >On GNU systems stdint.h still provides uint64_t, but I have no idea >how portable this is. is C99. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
[dev] Re: mksh build system
Cc’ing the mksh list. Feel free to keep it, redirect there, or remove it again. Christoph Lohmann dixit: >At least autoconf allows to specify a prefix, LDFLAGS or CFLAGS and some A prefix is only needed when the Makefile installs; Build.sh accepts the environment variables CC, CPPFLAGS, CFLAGS, LDFLAGS, LIBS, LDSTATIC as usual. >options like to clean the build directory. Just build in a separate tree… sh /path/to/mksh/Build.sh -r >This Build.sh is pure magic Oh come on… you’re either envious or don’t understand it. >which should be a sign of the past. It *is*. Running an autoconfigury is needed for portability to operating systems, especially older ones, that do not provide all required functionality in the currently used way. I try to keep it down to the minimum, and let it make sense too (e.g. if there’s three choices for something, and the first choice is found, the other two aren’t even probed, unlike GNU autoconf; and nothing that’s not used is probed, e.g. not whether sizeof(char)==1 or there’s an f77 compiler). I’ll be adding “mirtoconf” to paxmirabilis (MirBSD paxtar and cpio) too shortly – although I expect it to require *much* less… checks for some headers for the tape functions and for sizeof(off_t); I think that’s all. The idea behind this is to replace stuff like this… #if !defined(__INTERIX) && (!defined(__GLIBC__) || __GLIBC_PREREQ(2, 3)) #if !defined(__INTERIX) && !defined(__APPLE__) #if defined(__GLIBC__) … with proper checks. An ifdeffery depending on the target OS is imake(1) style instead, and *that* is a thing of the past which should rather be abolished. Your request for it to just build from a Makefile, with maybe a few user-adju‐ stable flags¹, would necessitate regressing to this. ① I never liked those user-adjustable flags anyway. Does a user know e.g. whether their off_t is long or long long? If they select the wrong one, they get a broken binary². I’d rather have some autoconfigury detect it. ② So happened in paxmirabilis – Linux/x32 is the only sane one to default to a 64 bit off_t, with a 32 bit long. 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: [dev] Is there any plan on a shell for sbase?
Christoph Lohmann dixit: >Remove this Build.sh crap and add some real Makefile and I will recon‐ >sider using it. You can let Build.sh generate a Makefile using the -M option, but that Makefile would then be specific to the system it ran on (actually “for”, not “on”, considering cross-compiling). This is done in MirBSD, MidnightBSD and Android currently. On GNU/Linux targets you would additionally need to provide signames.inc which is generated by Build.sh, or better, the libc should provide a sys_signame[] array. Note that Linux, kernel-side, has different signal names (even amount of them!) per architecture, and even libc… >wc -l Build.sh >2362 An equivalent autoconf crap would be ten to hundred times that size, FWIW. >Does this script really need to emulate autohell? Yes given mksh’s portability requirement. >Can’t a shell run in a minimal C function library subset which is >available everywhere? I wish. Really. mksh has very few imports, but the system-specific parts sadly vary greatly across OSes. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] Is there any plan on a shell for sbase?
Christoph Lohmann dixit: >* tab completion Can busybox ash do this? (If so, that’s recent.) > * Does this really need plugins? Definitely not; in mksh, tab completion is deterministic: the first word is expanded as command, all other words as files. Only downside is that tab completion is an editing feature, and as such gets confused by 'echo $(foo) ba' due to the closing parenthesis. >For now busybox ash is enough for all of this. I don’t think you should inflict ash on *anyone*. And mksh is not *that* much larger. I mean, even the Android people saw the light after a while… bye, //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: [dev] [sbase] changes to test
random...@fastmail.us dixit: >Okay - I'll get it in patch format later today, but it might be this >weekend before I have time to write a manpage - test has a _lot_ of >options. Feel free to take the test(1) description that’s part of https://www.mirbsd.org/man1/mksh as base (it’s in mdoc). bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] lynx?
Silvan Jegen dixit: >As a Vim user I see it the same way. In addition, correct me if I am >wrong but as far as I know lynx does not handle CJK characters >properly (German umlauts seem to work ok apparently). No, that works properly as long as you use libncursesw (one of the benefits of MirBSD over OpenBSD ☺). bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] lynx?
markus schnalke dixit: >you rather use w3m? Is there anyone on earth having figured out how to *use* that, as in navigate? Fernando C.V. dixit: >Also you can write rules for it that allow you to preprocess certain >websites or handle some of them differently, like running external >viewers for images, using youtube-dl when you open youtube urls, etc. Easily done in lynx. sta...@cs.tu-berlin.de dixit: >For interactive browsing in the terminal, I indeed use w3m more often -- >it renders often better. But, well not always, especially when menu and Better as in “more nice looking”, that I admit. But I found that it’s impossible for a text browser to both be navigatable _well_ and render tables “correctly”. For example, all links variants *and* www-wo-miru have the problem that, given a page that consists of a table like this: large text with lots of links more large text with lots of links Where the large text spans more than a screen page, even when in multiple s, that they make the link order (for up/down/tab) such that you have first all links from the left column, then all links for the right column, thus jumping back pages. Also, I found that they sometimes do horizontal scrolling. Lynx, while not being optimal, seems to decide to rather break the layout than do that. When I read “the web” it’s mostly information (as in: text) consumption, and for that, the layout is secondary. I do use links2 -g as “manga viewer” (even on file:/// stuff) because it’s got lynx-like navigation but is fast enough to display the pictures and does that inline. (And I found that it supports just enough ECMAscript for the cursor-right key on mangareader.net to DTRT.) But other than that and, when GUI stuff is needed, some maybe recent enough craprowser, Lynx is my primary webbrowser (and gopher client and ftp client when needed). (And my secondary newsreader… still prefer pine for that ☺). bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt
Re: [dev] upload via html?
Nicolas Braud-Santoni dixit: >Well, SFTP requires you to create a user account. (I'm aware that it may >not be one with which you can SSH in). >Some people might not want this. If someone does not have a user account on your site, they have no business uploading large files either. If you’re on GNU/Linux: nss_pgsql exists. You can easily provision those user accounts from some web application. Then use an anoncvssh-style shell to only permit SFTP and rsync (and possibly cvs, svn, git, etc.) and you’re set. Professional users will thank you for allowing rsync, and DAUs can just use sftp:// URLs in Konqueror or krusader. Or WinSCP… or zaSFTP on Windows Mobile. bye, //mirabilos -- │ untested │ tut natürlich │ was auch sonst ... │ fijn ☺
Re: [dev] Re: Why HTTP is so bad?
Nick dixit: >and hackable base. It's certainly in the interests of many >unpleasant organisations to force people to 'consume web content' in >the way proposed, such that it can't readily be scraped or changed, I think that thing is called “Television”. Not really sure, considering I stopped dealing with *that* at the age of nine. >but most definitely not in the interests of actual people. Right. I prefer my real web browser… see signature ☺ 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
Re: [dev] Re: Why HTTP is so bad?
Sam Watkins dixit: >Would you rather everyone is exchanging binary word documents >over sun-rpc, or something like that? How about plaintext over ssh, possibly with rsync-over-ssh? That’s Unix. (IMAPS and SMTP also work…) 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
[dev] Re: Why HTTP is so bad?
Andrew Gwozdziewycz dixit: >Not really, given that HTML has *nothing* to do with HTTP. Both are overused, really. >Of course, you often retrieve HTML documents via HTTP Doing anything else (well, file download is also okay), such as this XMLRPC crap, or even tunneling, over HTTP instead of just using plain TCP is probably the thing the original poster disagreed with. Me too, btw… it’s an illness of the age of the “webdesigner” ☹ >but I'm guessing >that you won't find reference to HTML in the HTTP RFC. AFAIK they mandate that XHTML be served as application/xml+xhtml instead of text/html, which the XHTML standard itself says to use for compatibility reasons (they also try to weasel in the application/xml+xhtml content type, but realise it won’t work). Nice when standards contradict each other like that. So yes, there’s a reference, but you’re better off ignoring it. Kinda like C11… also best ignored. bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc.
Re: [dev] [st] problem reading man pages
G David Modica dixit: >On 11:06 Wed 22 May , Thorsten Glaser wrote: >> How about: >> >> script man foo q exit >gdm@gdmThink ~$ script man foo q exit >bash: syntax error near unexpected token `newline' >gdm@gdmThink ~$ This is something to print out, frame and hang on the wall. … Honestly… bye, //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: [dev] [st] problem reading man pages
Fernando C.V. dixit: >rendered, but unreadable.. can you copy-paste the invisible spaces >between the "[-c ]"? How about: script man foo q exit Then send in the typescript, gzip(1)d. 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 dev@suckless.org
Re: [dev] gettext-stub
pancake dixit: > On 05/16/13 13:09, hiro wrote: >> http://penma.de/code/gettext-stub/ > > https://github.com/rofl0r/gettext-tiny https://www.mirbsd.org/MirOS/dist/hosted/libnointl/libnointl-20091122.tar.gz bye, //mirabilos PS: Contributors welcome, e.g. to provide the same API and, for the library, ABI that more recent GNU gettext versions than the one we had in MirPorts back then offer. -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Re: [dev] [dwm] Running dwm in KDE
Martin Miller dixit: >pkill -9 metacity && dwm In most environments, this will *not* work, as terminating the window manager will terminate your X session as well. >I've been given a laptop for work that's running Kubuntu. In the KDE >world is there something similar to metacity that I can kill so that I >can start dwm? Some OSes allow you to export WINDOWMANAGER or set the x-window-manager alternative using the alternatives system. KDE itself allows changing this in System Settings → Workspace Appearance and Behaviour → Default Applications. HTH & HAND, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
Re: [dev] upload via html?
Hugues Moretto-Viry dixit: >Could you explain me why FTP sucks? http://mywiki.wooledge.org/FtpMustDie 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: [dev] surf: typo in manpage
j. van den hoff dixit: > -.B Ctrl\-f and Ctrl\-\\ > currently, the corresponding line renders as "Ctrl-f and Ctrl-" when calling The nroff escape for a backslash is actually \e ☺ • https://www.mirbsd.org/manUSD/21.troff • https://www.mirbsd.org/manUSD/22.trofftut bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
Re: [dev] [PATCH v3] dmenu_run: Don't leave a shell running
Peter Hofmann dixit:
>I believe you can work around all these issues by simply prefixing the
>command piped to the shell with an "exec":
>
> dmenu_path | dmenu "$@" | sed 's/^/exec /' | ${SHELL:-"/bin/sh"} &
Won't necessarily work if the result is not a simple command, though…
FWIW:
tg@blau:~ $ cat >x1
#!/bin/sh
printf 'echo "Hello\tWorld!" | hexdump -C\n'
tg@blau:~ $ cat >x2
#!/bin/sh
eval exec "$(./x1)"
tg@blau:~ $ chmod +x x?
tg@blau:~ $ ./x2
48 65 6c 6c 6f 09 57 6f 72 6c 64 21 0a |Hello.World!.|
000d
So the tab is kept when you put Ross’ suggestion into double quotes.
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
Re: [dev] [PATCH v3] dmenu_run: Don't leave a shell running
Ross Lagerwall dixit: >+eval exec $(dmenu_path | dmenu "$@") You might need double-quotes around that (the eval argument). Best to check with something containing a tab, e.g. 「a\↹b "c↹d" e」 where ↹ is a tab. Sometimes spaces and quotes are not enough to show the issues. 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: [dev] System shell for sta.li
Jens Staal dixit: > Sorry for taking this out of context (and on the wrong list), but I built mksh > (now a relatively old version 40f) for Plan9/APE (using the native "cc" front > end to the plan9 compilers) in the hope to replace the old pdksh "sh" command > there. Yeah, I did that too. With ed, as I don’t get either sam or acme. > using -DMKSH_NOPROSPECTOFWORK, a (as far as I remember) unmodified mksh builds > and executes without complaining about absence of tty:s. The problem is that -DMKSH_NOPROSPECTOFWORK is not enough for a working mksh, it’s more or less a porting tool. If a specific behaviour exists without it but not with it, chances are it’s a kernel (in this case APE) bug: when you run a command, the shell doesn't return afterwards. We had that in Haiku, and when told at Chemnitzer Linux-Tage, they fixed their kernel bug overnight; mksh works on it ever since. (With -DMKSH_NOPROSPECTOFWORK things like co-processes don’t work, and who knows what else. The testsuite also hangs somewhere.) > Interestingly however, what happens if executing a command in this shell is > that the shell returns the written command with every character duplicated > (example: "exit" writes out "eexxiitt" before exiting the shell). Might be the terminal code. For Plan 9 you really need -DMKSH_NO_CMDLINE_EDITING since the terminal is “really dumb”. There’s a branch tg-mksh-plan9ape in CVS, though that’s older than mksh R28… I vaguely remember changing other things, back then. Never got really far, and -DMKSH_NOPROSPECTOFWORK just isn’t enough to call it a working port. But if you want to work on it, you’re most definitely welcome! bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: [dev] System shell for sta.li
Edgaras dixit: >Well it fails to compile on PI for me What OS? What error message? There was a period where a bug in GCC prevented a configure time check from working. In mksh R45 (released yesterday), the entire arithmetics code has been rewritten to not use signed integers, making that check obsolete, so if you got an error about a check with ari_sign_32_bit_and_wrap retry with R45. Otherwise… mksh is part of Debian/armel and Raspbian. >though admitedly I haven't givent it enough time maybe, also it's >build system is not suckless, to say it lightly, 2.5K lines >shellscript does not sound reasonable. It is when you look at the list of systems supported. >This custom build system might be responsible why I can not build it >on PI No, rather the other way round. Actually, it’s much better than say, GNU autoconf, because the checks have dependencies, and useless checks aren’t even run… >it fails to give any reasonable error message, some compile time >assertion fails, what a heck is that. Ah. That indeed is the GCC bug I mentioned earlier (GCC PR55009). The thing is, at the point you reached, the build script did not know about the GCC problem, and aborting there was the only sane failure mode because, in my opinion, better you get no mksh than one that cannot calculate correctly. An assertion is something that the author of the software thinks to be always true, so if it isn’t, something fishy happened. The packager is normally the person to compile the shell, not an end user, and they’d contact upstream using IRC or mailing lists and ask (though, the issue was documented on the mksh webpage). But, yesterday’s release of mksh R45 was done to precisely address this problem. Please give it a try. bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc.
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 AT&T 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: [dev] System shell for sta.li
Gregor Best dixit:
>didn't use mksh that long before switching from Linux to OpenBSD.
Nothing prevents you from replacing /bin/{,k}sh with mksh…
(I’ve done so on an OpenBSD VM at work) or just installing
it alongside and using it.
bye,
//mirabilos
PS: on that signature… Frank is zsh developer/committer.
--
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: [dev] [st] [PATCH] 8bit-meta like xterm
Roberto E. Vargas Caballero dixit: >It is the expected behaviour. As far as I know the first keyboard with meta >key was space-cadet keyboard (look it in Ah okay, thanks for the historic backup! >meta codes you have it configured for it (or maybe your xterm has a >different default configuration mine has). Probably. >I think it is easier a compose key, which allows you define non ascii >characteres using keystrokes (compose-key ' a -> á). This is the solution I >use in my USA keyboard and could generate spanish accents. Sure, that works too, and I use it for things like ① but Compose takes three keystrokes (up to five) sequentially, while Meta takes two or three in parallel (the “up to” is the shift key). The nice thing about ASCII and the QWERTY layout is that it has all ASCII characters easily available, so you can enter *all* latin1-subset-of-Unicode characters with just it. (In X11, I have additional mappings for stuff like € and … for which I used that “Caps Lock” key ☺). 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
Re: [dev] [st] [PATCH] 8bit-meta like xterm
Gregor Best dixit: >are added to your keyboard layout. Works fine with st, and the regular >"Left alt sends escape"-behaviour stays the same (and works fine with >irssi and the like). On the BSD text console and in default XTerm, the left Alt key acts as 8-bit enabling Meta key, so it’s *not* the same. (Also, I invested large effort to draft a keyboard layout based on this for Windows®, Linux®, XFree86®, etc.) 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: [dev] [st] [PATCH] 8bit-meta like xterm
random...@fastmail.us dixit:
>If this were an intended feature why would it elevate latin-1 over other
>unicode characters? This only proves my point.
It doesn’t – it’s just that latin1 is the first 256 chars of Unicode
by accident (or design, don’t know, ask the Unicode people).
And this Meta/8bit thing predates Unicode.
>And what the heck is wrong with national keyboard layouts that it's
>"useful" to "lead people away from" them?
/?\|[]{}'";:-_=+
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: [dev] [st] [PATCH] 8bit-meta like xterm
random...@fastmail.us dixit:
>Wait a minute... what exactly do you _expect_ meta to do? Using (for
>example) meta-a to type 0xE1 "a with acute" is _not_, in fact, the
>expected or intended behavior; it is a bug. And I don't think it will
No, it is the intended behaviour.
http://fsinfo.noone.org/~abe/typing-8bit.html
>even work with UTF-8 applications, and st is an exclusively UTF-8
>terminal.
XTerm handles that transparently: when in UTF-8 mode, Meta-d
is still CHR$(ASC("d")+128) = "ä", just U+00E4 instead of a
raw '\xE4' octet.
This is *extremely* useful – especially as it leads people
away from national keyboard layouts towards QWERTY while
retainig the ability to write business eMails, which require
correct spelling.
bye,
//mirabilos
--
17:57 < jtsn> Der 25C3 ist lustig. Deutsche Vortragende brechen sich vor
deutschen Zuhörern auf Englisch einen ab. ;-) 18:01 < jtsn> Adolfs Werk
war sehr nachhaltig. ;-)18:01 < jtsn> Das gab's nichtmal in der DDR,
das Deutsche mit Deutschen auf Russisch reden. ;-) (10x cnuke@)
Re: [dev] [st] double-width usage
Christoph Lohmann dixit: >Which applications do you use that handle double-width as you expect them? mksh and jupp (though I don’t use st). > Do these applications use the double-width for the layout? It’s possible to use Unicode characters, halfwidth or fullwidth, to draw nice boxen in either. >If double-width characters would be drawn to fit the standard cell size of the >terminal (drawing them in half the font size) would this suffice your need? Absolutely not. You need to distinguish by wcwidth() on the first character whether a given glyph (including the combining characters following it) fits into a halfwidth character cell or into a fullwidth character cell, which is exactly the width of two adjacent halfwidth character cells. Treating fullwidth as halfwidth, or the other way around, will not work. >Naming the applications would be important so I can test st to their >compatibility. Hrm, a shell and a text editor aren’t that good examples then… and I don’t have any good mixed example textfiles at hand. Sorry. But just this might be a PoC: ┌──┤ U+00A9 ├──┐ │ │ │ ䷀ │ │ ䷀ ䷀ │ │ ䷀ ䷀䷀ ䷀ │ │ ䷀ ䷀ ䷀ │ │ ䷀ ䷀ ䷀ │ │ ䷀ ䷀䷀ ䷀ │ │ ䷀ ䷀ │ │ ䷀ │ └──┘ I’m writing textfiles like that pretty often, and I use the creative heaven and fullwidth space in my own font editing tools (mksh script to convert between that and BDF, while doing the actual editing in a text editor and/or with ed and shell scripts). bye, //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
