Re: Script to extract portions of text from a text file

From: Stephane CHAZELAS (this.address_at_is.invalid)
Date: 12/16/04 

Date: Thu, 16 Dec 2004 09:58:25 +0000

2004-12-15, 11:27(-08), dfrench@mtxia.com:
[...]
>> set -o emacs
>> echi^Ho foo
>>
>> (where ^H is a BS character) is read differently from the tty
>> and from a script
>
>
> But your example is not comparing the same command. At the tty the ^H
> is interpreted by the tty driver

No, not in emacs mode, of course (the tty is put in raw and
noecho mode, otherwise ^B wouldn't move the cursor backward as
it wouldn't be sent to the shell until you press enter).

[...]
>> exec 3> /
>> behaves differently in a script and at the prompt
>
> I saw no difference in behavior between the command line and script in
> ksh93. Others should respond regarding other shells.

That's documented. If exec fails, it exits the shell in a
script. Not at the prompt.

[...]
>> echo > *
>
> I'll concede this one, however it is an extremely unlikely this command
> would actually be used from the command line or from a script.

Same for:

echo > $file

[...]
>> "read" has to read one character at a time until it finds a \n ,
>> because otherwise, expr would not be able to get the second
>> line of input (if it wanted to. It doesn't want but read
>> does not know that).
>
>
> How is the shell using a \n to designate the end of a line different
> from awk using the same character to designate the end of a line?

The shell does:

while (read(0, &c, 1) && c != '\n')...
  (one read system call per byte).

While awk does:

read(0, buf, 4096); processBufferToGetRecords()

> Most code is illegible if you don't know the syntax, that is why it's
> called code.

Sure, some are more legible than others.

I know few people who know that to read a line of input in
shell, it's IFS=<non-blanks> read -r line. It looked like that
even you didn't as you used to forget the "IFS=".

>> The right way being:
>>
>> cmd1 | awk '{ print substr($1, ...) }'
>
>
> Why is this code more legible than the previous code?

The shell is doing its job: running two commands piped together
cmd1 is doing its job: output what it has to output
awk is doing its job: text processing.

How could it be neater?

>
>> awk reads a whole buffer at a time, does the processing
>> internally.
>
> The shell generated the buffer for awk to read from. Sounds like an
> extra step to me.

No, cmd1 did, the shell didn't to anything on the data, it just
connected two applications together and left them do their job. 

-- 
Stephane

Relevant Pages

  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.questions)
  • Re: shell scripting
    ... and am assuming an sh-compatible shell here.... ... command 1 options arguments ... To run the script, do: ... then you need to use the full path to execute it: ...
    (comp.unix.shell)
  • Re: cd.exe
    ... hopefully will use the value of SHELL to invode the command. ... sets up the build environment and invokes bash. ... The script translates ... when invoked from the script though works fine from the command line. ...
    (comp.os.os2.programmer.porting)
  • Re: [PATCH] Linux 2.6: shebang handling in fs/binfmt_script.c
    ... script files and their interpreters (shells, awk, perl, python, guile, ... that that shell or interpreter would be poorly ... And, to be truthful, the usual way that I code awk scripts is not as ...
    (Linux-Kernel)
  • Re: [ Attn: Randy ] Ad-hoc Parsing?
    ... I can write and compile ... >>programs inside a shell, ... But for me it is essential, that the script ... > internal command), the this script can be executed even if there ...
    (alt.lang.asm)