<civodul>davexunit: keep pinging Mark Witmer so we get something we can all have fun with ;-) <davexunit>civodul: I'll let him know about the issues with xnest/xephyr next time I email him. <davexunit>ah, so that's MIT's radio station server. :) *davexunit noticed mark_weaver's hostname <Steap>Does anyone here know the ways of the Unix shell ? <Steap>I've justn oticed a strange behaviour: <Steap>$ echo -e "foo\\nbar\\nbaz" > /tmp/test && echo -e $(cat /tmp/test) <Steap>(yes, "echo $(cat ...)" is dummy, but it's just to reproduce the issue) <Steap>I would expect the newlines to be shown here; they appear when doing 'cat /tmp/test.py' <Steap>It's not really a huge issue to me, but if you know why this happens, I'd be glad to know <mark_weaver>well, $(...) does processing on the output of the command. by default, it breaks it up by whitespace. <mark_weaver>you can put the $(...) within double quotes, and then the output will be kept unchanged and as a single argument. <mark_weaver>also section 3.5 mentions the order of expansions: "brace expansion, tilde expansion, parameter, variable, and arithmetic expansion and command substitution (done in a left-to-right fashion), word splitting, and filename expansion." <mark_weaver>so word splitting and filename expansion happen after command substitution. <mark_weaver>so the final "echo" command gets four arguments: "-e", "foo", "bar", "baz". <Steap>As I expected, I'm just plain stupid <Steap>because there is no way I've never seen "$(...)" in a shell script before <mark_weaver>nah, the shell is very complex. too complex if you ask me. <Steap>well, not sure whether it's complex <Steap>or people my age are just not used to this kind of things *Steap is becoming quite old :) <taylanub>It makes some very specific complex tasks very easy, at a high price of other functionality, and is an overall mess ... <Steap>When you've learnt programming with Python <Steap>things like bash seem quite complicated <mark_weaver>shell semantics are definitely very complex. it's hard to keep it all in mind, even for experts. <Steap>Is that because of a bad design, or was it a really good piece of software when it came out ? <mark_weaver>well, when the first bourne shell came out, it was rather revolutionary that it was a normal program and not part of the operating system kernel. <mark_weaver>anyway, I suppose they just kept adding more features to it over time, and it kind of became a ball of mud. <mark_weaver>I guess the result is rather convenient to use as a command prompt, but it's not something to write robust software in, that's for sure. <Steap>I think I hate writing shell scripts as much as I love using the command line <Steap>Funny how people haven't switched to Python/Scheme/whatever for their sysadmin needs <mark_weaver>I suspect that quite a few sysadmins use Python and/or Perl for a lot of their sysadmin scripting needs. <Steap>Not sure whether switching from bash to Perl would be a huge improvement :D <mark_weaver>but for some simple scripts, the shell is convenient and easy, and it's lack of robustness regarding handling of special characters is not always a problem. <mark_weaver>heh, yeah, Perl was really big about 20 years ago, but thankfully it's on the decline. <mark_weaver>sorry, "it's on the decline" was right. "it's lack of robustness" should have been "its" instead. <mark_weaver>well, "it's" is supposed to be "it is", whereas "its" is supposed to be used to mean "belonging to it". but the latter meaning could be reasonably assigned to "it's" based on the rule that "FOO's" means belonging to "FOO". *gzg winders if guile-scs <gzg>*wonders if guile-scsh will ever gain traction. <gzg>Seems like it'd act well as a hybrid approach, on such a forming platform. ***elly_ is now known as elly
<civodul>"When using GNU Parallel to process data for publication please cite:" <civodul>When using GNU ls to list files, please cite: <civodul>yeah, its author seems much nicer and less egocentric ;-) <civodul>imagine if GCC were to do something similar, but proportional to the person-years spent on it <civodul>i guess it would play a one hour 3D video before you can proceed *civodul fixes "guix package -A | head" <civodul>it's interesting to see how Guile apps are robust to this by default <civodul>and making them as flaky as C apps requires quite a bit of effort <civodul>when you do that, you get EPIPE while writing to stdout <civodul>so Guile throws a system-error with EPIPE <civodul>and so you get a backtrace on stderr, and exit code 1 <civodul>whereas what you want here is to silently ignore the EPIPE <mark_weaver>so what makes you say that Guile apps are robust to this by default? <civodul>there are robust because write errors to stdout are systematically caught <mark_weaver>it would be nice to be able to ignore EPIPE on a per-port basis, so that you aren't tempted to ignore EPIPEs globally. <mark_weaver>now that we have port properties, it would be fairly straightforward to implement this. <mark_weaver>hmm, well, I guess you really want the program to exit, but exit cleanly in this case. <mark_weaver>well, nevermind this for now. I've already got too many tasks on my plate :) <civodul>but for now i have a leave-on-EPIPE macro that i use in cases where i know the only I/O is to stdout <civodul>clearly not perfect, but it solves this problem <civodul>in a ideal world, the system-error would carry the port