Shell Programming and Scripting

I want to display directory listing in the order of size. I do not have -S option in my version of UNIX. So I wrote a simple script. But it takes "| sort -n -k5,5" part as file names. Any suggestion?

Code:

#!/bin/ksh
 
cmd='ls -l *.TXT | sort -n -k 5,5'
set -x
$cmd
 
return 0

Firstly, I would add the -b flag to ignore leading blanks, just in case. You also need to beware that LDAP supported group names can contain spaces, so that throws things out of what as to what is the fifth field.

As you your problem, I would try splitting up your command more like this:-

Code:

cmd='ls -l *.TXT'
my_sort='sort -bnk5'
set -x
$cmd | $sort

Does this help?
Robin

Lowercase ls -s as an option is in the standards.
Upper case ls -S is not. What UNIX and version number are you on?

ls standards <- SUS2 from 1997 for the ls command. I'm suggesting perhaps you should have that option at least.

Thanks. It worked. But I am surprised why in my version it takes sort part as file names. I am getting errors as

Code:

|: No such file or directory
sort: No such file or directory
-n: No such file or directory
-k: No such file or directory
5,5: No such file or directory

---------- Post updated at 10:43 AM ---------- Previous update was at 10:39 AM ----------

Code:

ls -s

works. But I wanted long listing.

If you want a long listing, tell ls you want a long listing:

Code:

ls -ls

The reason is the way the shell parses its input. We tend to implicitly take for granted that spaces (or other whitespace) separate parts of the shells input (the "command line"), but that is not necessarily so. In fact the shell knows a character called "IFS" (the "internal field separator"), which is by default a blank but could be redefined to any other character:

Code:

$ echo abc:def:ghi | IFS=':' read field1 field2 field3
$ echo $field1 $field2 $field3

So we have an "internal field separator" and it is used to separate - fields. Because it is normally a blank the shell looks at a normal command line like this:

Code:

|| |-| |------| |------|
ls -la /bla/foo /foo/bar

The shell sees four fields, separated by the IFS character. The first field (ls)is taken - in absence of anything else - as a command. The next part (-la) is taken as the first argument and, because it is introduced by a hyphen and ls accepts options - it is interpreted as options. (Notice that, because of how getopts works, "-l-a", "-l -a" and "-la" work the same.) As the next argument comes (because getopts removes all options from the command line it is in fact the first) it is interpretd as argument to ls and so on.

This process is called "field splitting" and the shell does this to every (command) line it interpretes.

Now, what would happen if we slightly alter the command?

Code:

|| |-| |-----------------|
ls -la "/bla/foo /foo/bar"

the string /bla/foo /foo/bar would no longer be split because by enclosing it into quotes (in this case double and single quotes work the same) we told the shell to forego this field splitting process. It will therefore look for a directory /bla/foo /foo/bar and - if there is one - it will perform the ls -la command on it.

Now back to your original line:

cmd='ls -l *.TXT'
$cmd

With the first line (the single quotes) we told the shell to switch off field splitting for the string, so it is ONE string: ls -l *.TXT. This "holds" for exactly one evaluation of the string, therefore a command named ls -l *.TXT (literally!) is searched for - but perhaps not found.

You can try for yourself, execute this in your home dir:

Code:

cat - > ./"ls -l foo" <<EOF
#! /bin/sh

echo "here is the awkward command"
exit 0
EOF
chmod 754 "./ls -l foo"

you now have a file awkwardly named ls -l foo in your current directory. Now execute this:

Code:

cmd='ls -l foo'
./$cmd

And you will see that in fact this script is called. This in turn means that the whole string, including the whitespace, was intepreted as one field. Remove this script with the command rm "./ls -l foo".

This is all because the quoting protected the string from being subjugated to the field splitting process for one time. Notice, that if the string is interpreted a second time, this protection wears off:

Code:

cmd='ls -l foo'
eval $cmd

eval is a keyword which restarts the whole parsing process (and hence the field splitting) of the shell when reading this line. The line is interpreted twice and because of this the field splitting takes place (but only on the second pass, as some more intricate examples will show you - you may want to experiment and find out how to prevent/enforce this).

I hope this helps.

bakunin

Thanks bakunin for your explanation. Now I understood the real reason. Excellent.