« first day (3911 days earlier)      last day (39 days later) » 

9:32 AM
We need a badge for using multiple tools
-2
A: How to select only info start with pattern in a column and print in another one

Praveen Kumar BSawk 'NR>1' file| while read line; do frth=`echo -e "$line"| awk -F "[, ]" '{for(i=1;i<=NF;i++){if($i ~ /^S/){print $i}}}'|perl -pne "s/\n/,/g"|sed "s/,$//g"`;echo -e "$line $frth"; done|sed '1i id clade mutation S_mutation' output id clade mutation S_mutation 243 40A S:ojo,L:juju,S:...

AWK, shell read, AWK again, Perl, sed, sed
with AWK, Perl and the first sed in a loop, running on every single line
 
9:45 AM
@StephenKitt perhaps a variation of the Ig Nobel prize?
"UNIX anti-pattern" doesn't have a good ring to it
 
no use of cut neither cat ?
 
 
4 hours later…
2:11 PM
more tools = more better, right?
 
 
1 hour later…
3:27 PM
@jesse_b One tool for one job. It's unix.
 
@PrabhjotSingh one pipeline to rule them all
We all know how much @Kusalananda loves one liners
 
@jesse_b as opposed to pool liners
 
@jesse_b I remember Ed Morton saying "You don't need permutations of awk, sed and perl.". one or two weeks back.
 
Eh... There are times when it makes sense. There are some things that are trivial in Perl and other things that are trivial in awk, so for quick 'n dirty one-liners, it can sometimes make sense to combine them rather than implement the whole thing in one or the other.
 
Yup, for throwaway stuff I often use sed for string replacement even if I’m writing an AWK script because I find it easier than figuring out whatever gsub etc. call is best...
 
3:44 PM
exactly
 
Good all of my stuff is worthy of being called "throwaway"
 
4:38 PM
@Kusalananda zsh and fish both ignore ~/.profile by default? Seriously?
How about /etc/environment?
 
Yes. zsh reads /etc/zprofile and ~/.zprofile.
@terdon No shell reads that.
 
but not ~/.profile?
 
@terdon No. That file is for POSIX sh startup. Oh, and ksh.
... and bash if .bash_profile does'nt exist
I find it curious that peopple think that different shells should be compatible in so many different ways. They are different, so they behave differently.
 
@Kusalananda No shell sources that, but many read it. At least, you can set environment variables there and I know I asked Gilles to look over this answer of mine specifically because of that, so I doubt he'd have let me get away with this if it weren't true:
> You also have /etc/environment where you can set global environmental variables but that's read rather than sourced (commands inside it are not executed but variable definitions are set).
Dammit!
Oct 6 '15 at 16:14, by Gilles
@terdon By pam_env, so by the process that logs you in (login, sshd, xdm, …). It isn't read by a shell. If you want to test it, use something like ssh localhost.
 
/etc/environment is a file that some systems read he environment from before a shell is started. Or so I believe anyway.
There you go.
 
4:42 PM
grrrr
 
:-)
 
I could have sworn that ~/.profile was a general feature of bourne-family shells. So fish might not read it, fair enough, but zsh!?
Ah-ha! Hang on. This is from man zsh:
Sigh. Never mind. It does talk about ~/.profile, but I then realized that the paragraph above specifies it is referring to sh compatibility mode
 
I know the section, yes.
sh and ksh emulation.
 
So it's settled then? bash is better than zsh
backs away slowly
 
People do best in treating the different shells as different languages, each with their own quirks and configs and whatnot. Only if the shell has a sh compatibility mode can you say something that shell should behave like another shell, when in that mode.
 
4:46 PM
Bloody hell. This is annoying. I had this idea in my head that all shells that accept the var=value syntax for setting variables would read ~/.profile. Apparently, that was just wishful thinking.
 
I don't know about zsh in sh compatibility mode but I do know that doesn't mean much in bash
 
Every time I think I've gotten to the point where I can safely say I understand how shells work, one of you irritatingly knowledgeable folks shoots me down!
 
@jesse_b Well, in bash's case, it means, or example, that it does not read .bashrc or .bash_profile. Only .profile (and /etc/profile?)
 
$ bash --posix -c 'foo=(this should not work); [[ foobar =~ bar ]] && echo "${foo[@]}"'
this should not work
 
@jesse_b POSIX compatibility does not mean "disable all non-POSIX things".
It means "be compatible with POSIX", i.e. run a POSIX script as a POSIX shell should.
 
4:49 PM
But it should
 
If you feed a POSIX shell a non-POSIX script, then you obviously can't have any guarantees that it'll work. But with bash in POSIX mode, it may work anyway.
 
I'd rather run sh in --bash mode
I find it ironic that the posix option is a non posix option trollface.jpg
 
@jesse_b Nah, a POSIX shell wouldn't need it.
 
POSIX_ME_HARDER
 
5:27 PM
@jesse_b By the way, foo=(this should not work) is a perfectly good POSIX shell command. It runs should with the arguments not and work) with the environment variable foo set to (this.
Well, maybe not. But it would have been if the ( and ) had been quoted.
 
:-)
That's a bit odd actually. Why wouldn't foo=(this assign the string (this to foo?
 
because subshells are still valid in /bin/sh?
 
@jesse_b But not at that point in the grammar... Well well.
 
 
4 hours later…
9:26 PM
I'd be curious about the reasons (likely historical?) for the difference between ( ), which are metacharacters, and { }, which are not, in sh; so that foo=(bar command can't work while foo={bar command is fine.
 
10:04 PM
I've been writing off brazil nuts for most of my life because I don't know how to deshell them and just thought they tasted bad because I would always leave parts of the shell on but I got some pre shelled ones and they are really good
 
10:16 PM
@jesse_b Some of the shells are nuts.
 
 
2 hours later…
11:49 PM
@Kusalananda especially z shell
 

« first day (3911 days earlier)      last day (39 days later) »