What level of expertise will this interview item offer? unset foo; echo bar | read foo; echo $ foo
Imagine preparing for an in-depth technical interview and being asked to rate your knowledge of shell scripting (hypothetically on a scale of one to ten). Then review the following shell command line example and answer the questions: What does it do? and why?
unset foo; echo bar | read foo; echo "$foo"
What level of knowledge would you map out to correctly answer this question for the general case (and not just for one or another specific version of the shell)?
Now imagine given the following example:
cat "$SOMELIST_OF_HOSTS" | while read host; do ssh $host "$some_cmd"; done
... and the interviewer explains that this command is "not working" and that it only seems to be executing an ssh command on a few nodes listed in a (large) file (something like for every few hundred hostnames, apparently scattered from the list). Naturally, he asks: why is he doing this? and how can you fix it?
Then assess the level of knowledge you could match someone who can answer these questions correctly.
source to share
Note that the first example is shell specific. The pipe is an IPC (inter-process communication) operator, and the shell can do this by creating a subshell on either side of the pipe. (Technically, I suppose some wrapper might even evaluate both sides in separate sub-processes).
The command read
is built-in (should, in fact, be). Thus, in shells such as the bash
classic Bourne shell derivatives, the superprocess (subshell) is to the right of the pipe (read from the current shell), and the process ends after it read
(at the semicolon in this example). The Korn shell (at least as far back as 93) and zsh
put its subshell on the other side of the pipe and read data from them into the current process.
This is an interview question.
The point of my question here is to find some kind of consensus or metric on how to rate this level of question highly. This is not a matter of trivialities as it affects real world scripting and shell scripting portability, and it builds on a fundamental understanding of the underlying UNIX and shell semantics (IPC, pipes and subprocesses / subshells).
The second example is similar, but more subtle. I'll point out that the following change "works" ( ssh
will run on each of the hosts in the file):
cat $SOME_FILE | while read host; do ssh "$host" "$some_cmd" < /dev/null; done
The problem here is that the command ssh
buffers the input even if the command on the remote doesn't read it from stdin. Since the shell / subshell (read from a pipe) and ssh
use the same input stream, it ssh
"steals" most of the input from the pipeline, leaving only a random line for the command read
.
This is not an artificial question. I actually ran into this in my work and had to figure it out. I know from experience that understanding this second example is at least a notch or two above the first. I also know, also from years of experience, that less than 10% of candidates (for sysadmins and programming positions) that I interview can get the first question right away).
I have never used the second question in a live interview, and I was discouraged to do so.
source to share
The first is the novice intermediate level (see below). unset
, echo
, read
And use of essential variables should occur within the first 1000 lines so Bash or working with a typical shell code.
The second is IMO intermediate level; I used Bash for several years before learning about harmless commands like ssh
gobbling standard input. This is a good test for the team ssh
, but since this is a bit of an anomaly it would be better to test with just cat
to see if the candidate understands the underlying problem.
But as I think @ IgnacioVazquez-Abrams points out, you can't judge a lot based on only two narrow questions. As others have pointed out why not just give them the actual problem to work with? You will get an infinitely better idea of their ability to actually get the job .
Edit: As Ignacio Vasquez-Abrams pointed out, they are essentially experiencing the same thing. So I would appreciate both intermediate ones.
source to share