Mixing
KSH script emulating GNU 'ls' command returns only one result when parameter is used
I've been trying to utilize this script given to me to highlight directories and other files on an AIX box...
Using:
/script/location/directory/lsc.sh -la
works fine. Highlights everything properly, etc.
Using:
/script/location/directory/lsc.sh -la *specific_parameter*
returns only the first record that matches with the parameter and none of the others(which there is at least a dozen or so actual matches).
My experience with shell scripting is lacking a bit in comparison to other languages I use. I'm not sure if it's something obvious or not that is causing it to only return the one result and what a possible solution would be to allow proper ls-like functionality.
Any suggestions? Thank you in advance for your time and help.
Below is the script itself:
#!/bin/ksh
#***************************************************************************
#***************************************************************************
#* Check to see if any parameters were passed. If not, just list files. *
#***************************************************************************
if [[ $1 = "" || $(echo $1|cut -b1) = "/" ]]
then
ls $1
exit 0
fi
#***************************************************************************
#* Issue ls with parameters, send to a tmp file *
#* $1 is any ls parameters - ie -la *
#* $2 may be a directory other than CWD - ie /etc *
#* the grep -v is in case this is issued in home dir - we dont want to see *
#* our tmp file since it will be deleted when this script finishes. *
#***************************************************************************
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
#***************************************************************************
#* Process the file. *
#* If dir: blue, link: light blue, char/block device: inverse blue, white *
#* socket: red, everything else: no color *
#***************************************************************************
while read LINE
do
TYPE=$(echo $LINE|cut -b1)
case $TYPE in
d) echo "33[0;91m$LINE33[0m" ;;
l) echo "33[0;92m$LINE33[0m" ;;
[cb]) echo "33[44;37m$LINE33[0m" ;;
s) echo "33[0;31m$LINE33[0m" ;;
-) if [[ $(echo $LINE|cut -b4) = "x" ||
$(echo $LINE|cut -b7) = "x" ||
$(echo $LINE|cut -b10) = "x" ]]
then
echo "33[0;96m$LINE33[0m"
else
echo "33[0m$LINE"
fi ;;
*) echo "33[0m$LINE" ;;
esac
done < ${HOME}/$$.tmp
#***************************************************************************
#* Clean up the tmp file *
#***************************************************************************
rm ${HOME}/$$.tmp
shell unix ksh ls
asked Nov 19 '18 at 16:41
Luke Liddell
32
add a comment |
I've been trying to utilize this script given to me to highlight directories and other files on an AIX box...
Using:
/script/location/directory/lsc.sh -la
works fine. Highlights everything properly, etc.
Using:
/script/location/directory/lsc.sh -la *specific_parameter*
returns only the first record that matches with the parameter and none of the others(which there is at least a dozen or so actual matches).
My experience with shell scripting is lacking a bit in comparison to other languages I use. I'm not sure if it's something obvious or not that is causing it to only return the one result and what a possible solution would be to allow proper ls-like functionality.
Any suggestions? Thank you in advance for your time and help.
Below is the script itself:
#!/bin/ksh
#***************************************************************************
#***************************************************************************
#* Check to see if any parameters were passed. If not, just list files. *
#***************************************************************************
if [[ $1 = "" || $(echo $1|cut -b1) = "/" ]]
then
ls $1
exit 0
fi
#***************************************************************************
#* Issue ls with parameters, send to a tmp file *
#* $1 is any ls parameters - ie -la *
#* $2 may be a directory other than CWD - ie /etc *
#* the grep -v is in case this is issued in home dir - we dont want to see *
#* our tmp file since it will be deleted when this script finishes. *
#***************************************************************************
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
#***************************************************************************
#* Process the file. *
#* If dir: blue, link: light blue, char/block device: inverse blue, white *
#* socket: red, everything else: no color *
#***************************************************************************
while read LINE
do
TYPE=$(echo $LINE|cut -b1)
case $TYPE in
d) echo "33[0;91m$LINE33[0m" ;;
l) echo "33[0;92m$LINE33[0m" ;;
[cb]) echo "33[44;37m$LINE33[0m" ;;
s) echo "33[0;31m$LINE33[0m" ;;
-) if [[ $(echo $LINE|cut -b4) = "x" ||
$(echo $LINE|cut -b7) = "x" ||
$(echo $LINE|cut -b10) = "x" ]]
then
echo "33[0;96m$LINE33[0m"
else
echo "33[0m$LINE"
fi ;;
*) echo "33[0m$LINE" ;;
esac
done < ${HOME}/$$.tmp
#***************************************************************************
#* Clean up the tmp file *
#***************************************************************************
rm ${HOME}/$$.tmp
shell unix ksh ls
asked Nov 19 '18 at 16:41
Luke Liddell
32
1
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58
add a comment |
I've been trying to utilize this script given to me to highlight directories and other files on an AIX box...
Using:
/script/location/directory/lsc.sh -la
works fine. Highlights everything properly, etc.
Using:
/script/location/directory/lsc.sh -la *specific_parameter*
returns only the first record that matches with the parameter and none of the others(which there is at least a dozen or so actual matches).
My experience with shell scripting is lacking a bit in comparison to other languages I use. I'm not sure if it's something obvious or not that is causing it to only return the one result and what a possible solution would be to allow proper ls-like functionality.
Any suggestions? Thank you in advance for your time and help.
Below is the script itself:
#!/bin/ksh
#***************************************************************************
#***************************************************************************
#* Check to see if any parameters were passed. If not, just list files. *
#***************************************************************************
if [[ $1 = "" || $(echo $1|cut -b1) = "/" ]]
then
ls $1
exit 0
fi
#***************************************************************************
#* Issue ls with parameters, send to a tmp file *
#* $1 is any ls parameters - ie -la *
#* $2 may be a directory other than CWD - ie /etc *
#* the grep -v is in case this is issued in home dir - we dont want to see *
#* our tmp file since it will be deleted when this script finishes. *
#***************************************************************************
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
#***************************************************************************
#* Process the file. *
#* If dir: blue, link: light blue, char/block device: inverse blue, white *
#* socket: red, everything else: no color *
#***************************************************************************
while read LINE
do
TYPE=$(echo $LINE|cut -b1)
case $TYPE in
d) echo "33[0;91m$LINE33[0m" ;;
l) echo "33[0;92m$LINE33[0m" ;;
[cb]) echo "33[44;37m$LINE33[0m" ;;
s) echo "33[0;31m$LINE33[0m" ;;
-) if [[ $(echo $LINE|cut -b4) = "x" ||
$(echo $LINE|cut -b7) = "x" ||
$(echo $LINE|cut -b10) = "x" ]]
then
echo "33[0;96m$LINE33[0m"
else
echo "33[0m$LINE"
fi ;;
*) echo "33[0m$LINE" ;;
esac
done < ${HOME}/$$.tmp
#***************************************************************************
#* Clean up the tmp file *
#***************************************************************************
rm ${HOME}/$$.tmp
shell unix ksh ls
asked Nov 19 '18 at 16:41
Luke Liddell
32
I've been trying to utilize this script given to me to highlight directories and other files on an AIX box...
Using:
/script/location/directory/lsc.sh -la
works fine. Highlights everything properly, etc.
Using:
/script/location/directory/lsc.sh -la *specific_parameter*
returns only the first record that matches with the parameter and none of the others(which there is at least a dozen or so actual matches).
My experience with shell scripting is lacking a bit in comparison to other languages I use. I'm not sure if it's something obvious or not that is causing it to only return the one result and what a possible solution would be to allow proper ls-like functionality.
Any suggestions? Thank you in advance for your time and help.
Below is the script itself:
#!/bin/ksh
#***************************************************************************
#***************************************************************************
#* Check to see if any parameters were passed. If not, just list files. *
#***************************************************************************
if [[ $1 = "" || $(echo $1|cut -b1) = "/" ]]
then
ls $1
exit 0
fi
#***************************************************************************
#* Issue ls with parameters, send to a tmp file *
#* $1 is any ls parameters - ie -la *
#* $2 may be a directory other than CWD - ie /etc *
#* the grep -v is in case this is issued in home dir - we dont want to see *
#* our tmp file since it will be deleted when this script finishes. *
#***************************************************************************
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
#***************************************************************************
#* Process the file. *
#* If dir: blue, link: light blue, char/block device: inverse blue, white *
#* socket: red, everything else: no color *
#***************************************************************************
while read LINE
do
TYPE=$(echo $LINE|cut -b1)
case $TYPE in
d) echo "33[0;91m$LINE33[0m" ;;
l) echo "33[0;92m$LINE33[0m" ;;
[cb]) echo "33[44;37m$LINE33[0m" ;;
s) echo "33[0;31m$LINE33[0m" ;;
-) if [[ $(echo $LINE|cut -b4) = "x" ||
$(echo $LINE|cut -b7) = "x" ||
$(echo $LINE|cut -b10) = "x" ]]
then
echo "33[0;96m$LINE33[0m"
else
echo "33[0m$LINE"
fi ;;
*) echo "33[0m$LINE" ;;
esac
done < ${HOME}/$$.tmp
#***************************************************************************
#* Clean up the tmp file *
#***************************************************************************
rm ${HOME}/$$.tmp
shell unix ksh ls
shell unix ksh ls
asked Nov 19 '18 at 16:41
Luke Liddell
32
asked Nov 19 '18 at 16:41
Luke Liddell
32
asked Nov 19 '18 at 16:41
Luke Liddell
32
asked Nov 19 '18 at 16:41
Luke Liddell
32
asked Nov 19 '18 at 16:41
Luke Liddell
32
32
1
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58
add a comment |
1
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58
1
1
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58
add a comment |
1 Answer
1
active
oldest
votes
Not a great script, but then you are not using it like it was intented to work IMHO.
/script/location/directory/lsc.sh -la
$1: -la
$2: nothing
/script/location/directory/lsc.sh -la *something*
The shell does wildcard expansion like this:
/script/location/directory/lsc.sh -la 1something1 2something2 3something3 ...
So wildcard expansion happends before the script is called.
Therefore, with that last call of lsc.sh:
$1: -la
$2: 1something1
and the script does ls $1 $2 so only the first directory is processed, which is what you see.
If you want it to process all arguments, after wildcard expansion, replace:
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
by
args=$1
shift
ls $args $@ | grep -v $$.tmp >> ${HOME}/$$.tmp
I found the script here: https://www.tek-tips.com/faqs.cfm?fid=6627
One of the most common link you will see here is "Why not parse ls" at link https://unix.stackexchange.com/questions/128985/why-not-parse-ls-and-what-do-to-instead
The other thing I cannot garantee that this fix will work for all wildcard conditions, so it is provided 'as-is', YMMV.
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
Oh, I was late, I just wanted to suggest usingls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp
– Lorinczy Zsigmond
Nov 19 '18 at 18:28
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53379125%2fksh-script-emulating-gnu-ls-command-returns-only-one-result-when-parameter-is%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Not a great script, but then you are not using it like it was intented to work IMHO.
/script/location/directory/lsc.sh -la
$1: -la
$2: nothing
/script/location/directory/lsc.sh -la *something*
The shell does wildcard expansion like this:
/script/location/directory/lsc.sh -la 1something1 2something2 3something3 ...
So wildcard expansion happends before the script is called.
Therefore, with that last call of lsc.sh:
$1: -la
$2: 1something1
and the script does ls $1 $2 so only the first directory is processed, which is what you see.
If you want it to process all arguments, after wildcard expansion, replace:
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
by
args=$1
shift
ls $args $@ | grep -v $$.tmp >> ${HOME}/$$.tmp
I found the script here: https://www.tek-tips.com/faqs.cfm?fid=6627
One of the most common link you will see here is "Why not parse ls" at link https://unix.stackexchange.com/questions/128985/why-not-parse-ls-and-what-do-to-instead
The other thing I cannot garantee that this fix will work for all wildcard conditions, so it is provided 'as-is', YMMV.
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
Oh, I was late, I just wanted to suggest usingls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp
– Lorinczy Zsigmond
Nov 19 '18 at 18:28
add a comment |
Not a great script, but then you are not using it like it was intented to work IMHO.
/script/location/directory/lsc.sh -la
$1: -la
$2: nothing
/script/location/directory/lsc.sh -la *something*
The shell does wildcard expansion like this:
/script/location/directory/lsc.sh -la 1something1 2something2 3something3 ...
So wildcard expansion happends before the script is called.
Therefore, with that last call of lsc.sh:
$1: -la
$2: 1something1
and the script does ls $1 $2 so only the first directory is processed, which is what you see.
If you want it to process all arguments, after wildcard expansion, replace:
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
by
args=$1
shift
ls $args $@ | grep -v $$.tmp >> ${HOME}/$$.tmp
I found the script here: https://www.tek-tips.com/faqs.cfm?fid=6627
One of the most common link you will see here is "Why not parse ls" at link https://unix.stackexchange.com/questions/128985/why-not-parse-ls-and-what-do-to-instead
The other thing I cannot garantee that this fix will work for all wildcard conditions, so it is provided 'as-is', YMMV.
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
Oh, I was late, I just wanted to suggest usingls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp
– Lorinczy Zsigmond
Nov 19 '18 at 18:28
add a comment |
Not a great script, but then you are not using it like it was intented to work IMHO.
/script/location/directory/lsc.sh -la
$1: -la
$2: nothing
/script/location/directory/lsc.sh -la *something*
The shell does wildcard expansion like this:
/script/location/directory/lsc.sh -la 1something1 2something2 3something3 ...
So wildcard expansion happends before the script is called.
Therefore, with that last call of lsc.sh:
$1: -la
$2: 1something1
and the script does ls $1 $2 so only the first directory is processed, which is what you see.
If you want it to process all arguments, after wildcard expansion, replace:
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
by
args=$1
shift
ls $args $@ | grep -v $$.tmp >> ${HOME}/$$.tmp
I found the script here: https://www.tek-tips.com/faqs.cfm?fid=6627
One of the most common link you will see here is "Why not parse ls" at link https://unix.stackexchange.com/questions/128985/why-not-parse-ls-and-what-do-to-instead
The other thing I cannot garantee that this fix will work for all wildcard conditions, so it is provided 'as-is', YMMV.
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
Not a great script, but then you are not using it like it was intented to work IMHO.
/script/location/directory/lsc.sh -la
$1: -la
$2: nothing
/script/location/directory/lsc.sh -la *something*
The shell does wildcard expansion like this:
/script/location/directory/lsc.sh -la 1something1 2something2 3something3 ...
So wildcard expansion happends before the script is called.
Therefore, with that last call of lsc.sh:
$1: -la
$2: 1something1
and the script does ls $1 $2 so only the first directory is processed, which is what you see.
If you want it to process all arguments, after wildcard expansion, replace:
ls $1 $2 | grep -v $$.tmp >> ${HOME}/$$.tmp
by
args=$1
shift
ls $args $@ | grep -v $$.tmp >> ${HOME}/$$.tmp
I found the script here: https://www.tek-tips.com/faqs.cfm?fid=6627
One of the most common link you will see here is "Why not parse ls" at link https://unix.stackexchange.com/questions/128985/why-not-parse-ls-and-what-do-to-instead
The other thing I cannot garantee that this fix will work for all wildcard conditions, so it is provided 'as-is', YMMV.
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
answered Nov 19 '18 at 18:02
Nic3500
3,32281829
3,32281829
Oh, I was late, I just wanted to suggest usingls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp
– Lorinczy Zsigmond
Nov 19 '18 at 18:28
add a comment |
Oh, I was late, I just wanted to suggest usingls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp
– Lorinczy Zsigmond
Nov 19 '18 at 18:28
Oh, I was late, I just wanted to suggest using
ls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp– Lorinczy Zsigmond
Nov 19 '18 at 18:28
Oh, I was late, I just wanted to suggest using
ls -l "$@" | grep -v $$.tmp >>${HOME}/$$.tmp– Lorinczy Zsigmond
Nov 19 '18 at 18:28
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53379125%2fksh-script-emulating-gnu-ls-command-returns-only-one-result-when-parameter-is%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
This script is broken. Return it to the vendor and ask your money back.
– Lorinczy Zsigmond
Nov 19 '18 at 16:58