Shell What is the best practice to learn SHELL/BASH

[blind0ne]

One more question, if I want to do something like this in running shell not in script how it's possible at all?

root@OffGateway:/code/sh/parsing_day_3 # cat example.file | \
while read line\
do\
echo "${line}"\
done/
>
> \
>
> \\
>
>

Pressing enter is just appending new lines with >

 

[covacat]

while read a;do echo $a;done </some/file

 

[Vull]

One more question, if I want to do something like this in running shell not in script how it's possible at all?

root@OffGateway:/code/sh/parsing_day_3 # cat example.file | \ while read line\ do\ echo "${line}"\ done/ > > \ > > \\ > >
Pressing enter is just appending new lines wiht >

Syntax error: done/ should be done

The shell is waiting for you to enter the keyword done

Edited to add: covacat's alternative is a more efficient way to accomplish the same job, because:

1. It avoids an unnecessary pipe,
2. It avoids invoking the external program cat,
3. It's, in general, slightly more terse, and
4. The shell only has to parse a single line instead of five.

 

[SirDice]

The > is called a continuation prompt. It means the shell is still expecting the command line to continue on the next line. In this case it's because the do hasn't been closed off with a done (done/ is a syntax error, thus not recognized). You can usually exit it with CTRL-D (will still execute the code upto the syntax error) or CTRL-C (breaks off the whole command line).

 

[astyle]

Hmmm... in college, I was taught that the > and < are for output and input redirection. Never got a good handle on <, but for >, you can do something like this:

% echo "Hello, world!" > hello.txt # Note the one '>' ! This will overwrite an existing hello.txt (or create a new one if a file by that name is not there already).
% cat hello.txt
Hello, world!
% echo "Hello, neko-chan!" >> hello.txt  # Note the two '>' ! This will tack a line to the end of hello.txt
% cat hello.txt
Hello, world!
Hello, neko-chan!
% cat hello.txt | grep hello # Nothing will happen, why? Left as homework for OP :cool:
%

 

[SirDice]

in college, I was taught that the > and < are for output and input redirection.

As arguments on the command line, yes. As a prompt, no, then it's just a character. Just try this on the command line with a bourne shell, then you'll see what I mean with a continuation prompt.

while true; do

You can even set it to a different prompt by setting PS2:

PS2="Still in the command line> "
while true; do

     PS2           The secondary prompt string, which defaults to “> ”.  PS2
                   may include any of the formatting sequences from PS1.

 

[eternal_noob]

Very interesting thread. Thanks blind0ne for creating it.

I admit that i first thought that this was another "tell the noob how to do it and then forget" thread but there is very substantial information here.
Thanks to everyone for participating.

 

[astyle]

Very interesting thread. Thanks blind0ne for creating it.

I admit that i first thought that this was another "tell the noob how to do it and then forget" thread but there is very substantial information here.
Thanks to everyone for participating.

I'd upvote THAT if the forums here provided such a feature. I completely agree with eternal_noob 's assessment. I also think that we're kind of lucky it turned out this way - not all threads are like that, but we all contribute to a thread being a productive conversation with substantial info - or a flame war. Just sayin'...

 

[gpw928]

But each one of those causes a fork(2) and exec(2), so there is something of an issue with execution speed...

This has cost me some sleep, and I feel compelled to correct the record.
Using eval in the shell will cause a fork(2) so the shell can re-read and evaluate the expression, but not an exec(2).
So there is still an expensive system call for each eval, which slows things down a lot, but it's not as bad as I indicated.

 

[covacat]

This has cost me some sleep, and I feel compelled to correct the record.
Using eval in the shell will cause a fork(2) so the shell can re-read and evaluate the expression, but not an exec(2).
So there is still an expensive system call for each eval, which slows things down a lot, but it's not as bad as I indicated.

eval does not fork

#/bin/sh
PID='$$'
eval echo "INNER PID:$$ OUTER PID:$PID"
echo $(/bin/sh -c "echo INNER PID:$$ OUTER PID:$PID")

 

[gpw928]

You are correct:

# echo $$
31478
# eval echo '$$'
31478

My information was obsolete...