I found GNU parallel to be very useful/cool.
The most surprising Unix programs
131–140 of 182 posts
Re: The most surprising Unix programs
#132For me, the most surprising one was paste. paste allowed me to interleave to streams or to split out a single stream into two columns. I'd been writing custom scripting monstrosities before I discovered paste: $ paste I wonder what other unix gems I've been missing...
The related join(1) and comm(1) are oft-missed and occasionally helpful.
I'm going through the AWK book and join is in there. I was unhappily surprised to find that using a tab as a delimiter is painful with join.
Variations to overcome this which I've bumped into:
join -t $'\t' file1 file2 (BASH only, I think.)
join -t '' file1 file2
join -t "`echo '\t'`" file1 file2
Re: The most surprising Unix programs
#133Earlier quoted context omitted.
Yeah, Rust’s compiler errors are decent if you make simple mistakes but degrade to being about as bad as any other modern compiler’s once you start doing complicated things. Which isn’t horrible, but --explain isn’t really useful so it’s just wasting space on my screen.
Please file bugs for any message that is confusing! We track them like any other bug, and there’s some folks actively working on them.
I'll keep that in mind for future interaction with rustc, thanks. Just to double check, you are referring to Github issues on the rust-lang/rust repository, right?
Re: The most surprising Unix programs
#134Earlier quoted context omitted.
Hmm, I wouldn’t call them confusing per se, they’re just not useful, and I don’t think any compiler has really solved this problem (but then again, generation of compiler error messages is not something I’m an expert in). Let’s say I forgot to put a “*” in front of something: the compiler’s error might be something like “xyz does not implement SomeTrait, here is a page explaining what traits are”. I’d be more than ha…
Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug. > I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area. It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then…
> Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug.
That's a fantastic attitude and I really appreciate that someone is working towards that goal, thanks.
> It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then ship. And then look at the next error.
Exactly. That person is a saint.
Re: The most surprising Unix programs
#135Earlier quoted context omitted.
Hmm, I wouldn’t call them confusing per se, they’re just not useful, and I don’t think any compiler has really solved this problem (but then again, generation of compiler error messages is not something I’m an expert in). Let’s say I forgot to put a “*” in front of something: the compiler’s error might be something like “xyz does not implement SomeTrait, here is a page explaining what traits are”. I’d be more than ha…
Let us determine if it's possible or not. The person who currently works on errors is of the opinion that any time the error isn't useful, it's a bug. > I’m genuinely curious to hear if there’s any strategies on improving these or work done in this area. It's just a ton of work. You look at what the compiler produces, look at what information you can have at that point, see if you can craft something better, and then…
I have no issue with filing bugs about errors I think aren’t great, aside from the fact that I might not be able to suggest anything better…I’ll try it out the next time I see something.
Re: The most surprising Unix programs
#136Earlier quoted context omitted.
The related join(1) and comm(1) are oft-missed and occasionally helpful.
I'm going through the AWK book and join is in there. I was unhappily surprised to find that using a tab as a delimiter is painful with join. Variations to overcome this which I've bumped into: join -t $'\t' file1 file2 (BASH only, I think.) join -t ' ' file1 file2 join -t "`echo '\t'`" file1 file2 Why 'join -t '\t' file1 file2' is apparently beyond the pale has me mystified.
Given that the delimiter must be a single character and the intended use is in shells, I am equally mystified as to why control codes must be passed literally. Join is smart enough to reject 2 character delimiters, but could easily grok escapes if it so chose:
$ join -t '\t' join: illegal tab character specification
Re: The most surprising Unix programs
#137Earlier quoted context omitted.
In the 40s, computing was seen as primarily women's work (similar to the stereotype of switchboard operators). Into the 60s, women still comprised up to half of the computing workforce. In 84, they peaked at 37%. So demographically speaking, the ratio was not as bad as it is today. (Source: https://en.wikipedia.org/wiki/Women_in_computing )
Into the 60s, women still comprised up to half of the computing workforce. My life experience corroborates this. When I was in school, girls were taught to type, and boys weren't. Because of that, many of the girls from my school went into computing, while the boys went to more "manly" pursuits. It's also why Catholic nuns were over-represented in early computing.
"It's also why Catholic nuns were over-represented in early computing."
Would you mind expanding on that?
Re: The most surprising Unix programs
#138There's a very simple system tool that clicked on about 50 simultaneous lightbulbs in my brain after only 10 minutes of playing with it: mkfifo
I learned about it through a plugin for irssi, which lets you have a list of users in an IRC channel in a tmux window partition.
Re: The most surprising Unix programs
#139Earlier quoted context omitted.
Ok I'm probably showing my age here then :) Back in the 1980 and 1990s, the roff suite, and most definitely egrep and classic Thompson DFA construction and DFA->NFA conversion was definitely Unix folklore/taught in Uni. Manpages are still rendered using roff/groff today, so probably many of us are using it regularly. Whereas GNU's texinfo has matured less well I'd say, or wasn't even very useful in practice to begin…
> and most definitely egrep and classic Thompson DFA construction and DFA->NFA conversion was definitely Unix folklore/taught in Uni I think you mean "Thompson NFA construction" and "NFA->DFA." Regardless though, this is not what the OP is pointing out. 'egrep' (or just GNU grep these days) is doing something more clever (emphasis mine): > Al Aho expected his deterministic regular-expression recognizer would beat Ken…
> I think you mean "Thompson NFA construction" and "NFA->DFA."
Yep, only noticed it later, then left it in to see who's paying attention :)
Re: The most surprising Unix programs
#140What does he man by "record structure in the file system" in re to Multics?