Calling sh with script on stdin and passing command line arguments











up vote
-3
down vote

favorite












This works of course. I can run ./test1.sh cats and the argument cats is passed correctly to ls.



$ cat test1.sh
#!/bin/sh
ls -l $1


Can you tell me how do I make this second example — the same content as the first one, but encrypted — work the same way? The password is "password". openssl outputs the above script, and ls -l runs, but how do I pass the command line argument to it?



$ cat test2.sh
#!/bin/sh
echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"|openssl enc -base64 -d -aes-256-cbc|sh $1


To clarify, test2.sh is equivalent to



$ cat test3.sh
#!/bin/sh
printf '%sn' '#!/bin/sh' 'ls -l $1' | sh $1









share|improve this question









New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • What do you want the script to do with the argument?
    – Scott
    2 days ago










  • Same as in test1.sh, pass it to ls -l.
    – Jack Brown
    2 days ago








  • 1




    There's no ls -l in test2.sh
    – muru
    2 days ago






  • 1




    @muru There is, inside the encrypted script in test2.sh.
    – Kusalananda
    2 days ago















up vote
-3
down vote

favorite












This works of course. I can run ./test1.sh cats and the argument cats is passed correctly to ls.



$ cat test1.sh
#!/bin/sh
ls -l $1


Can you tell me how do I make this second example — the same content as the first one, but encrypted — work the same way? The password is "password". openssl outputs the above script, and ls -l runs, but how do I pass the command line argument to it?



$ cat test2.sh
#!/bin/sh
echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"|openssl enc -base64 -d -aes-256-cbc|sh $1


To clarify, test2.sh is equivalent to



$ cat test3.sh
#!/bin/sh
printf '%sn' '#!/bin/sh' 'ls -l $1' | sh $1









share|improve this question









New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • What do you want the script to do with the argument?
    – Scott
    2 days ago










  • Same as in test1.sh, pass it to ls -l.
    – Jack Brown
    2 days ago








  • 1




    There's no ls -l in test2.sh
    – muru
    2 days ago






  • 1




    @muru There is, inside the encrypted script in test2.sh.
    – Kusalananda
    2 days ago













up vote
-3
down vote

favorite









up vote
-3
down vote

favorite











This works of course. I can run ./test1.sh cats and the argument cats is passed correctly to ls.



$ cat test1.sh
#!/bin/sh
ls -l $1


Can you tell me how do I make this second example — the same content as the first one, but encrypted — work the same way? The password is "password". openssl outputs the above script, and ls -l runs, but how do I pass the command line argument to it?



$ cat test2.sh
#!/bin/sh
echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"|openssl enc -base64 -d -aes-256-cbc|sh $1


To clarify, test2.sh is equivalent to



$ cat test3.sh
#!/bin/sh
printf '%sn' '#!/bin/sh' 'ls -l $1' | sh $1









share|improve this question









New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











This works of course. I can run ./test1.sh cats and the argument cats is passed correctly to ls.



$ cat test1.sh
#!/bin/sh
ls -l $1


Can you tell me how do I make this second example — the same content as the first one, but encrypted — work the same way? The password is "password". openssl outputs the above script, and ls -l runs, but how do I pass the command line argument to it?



$ cat test2.sh
#!/bin/sh
echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"|openssl enc -base64 -d -aes-256-cbc|sh $1


To clarify, test2.sh is equivalent to



$ cat test3.sh
#!/bin/sh
printf '%sn' '#!/bin/sh' 'ls -l $1' | sh $1






bash scripting pipe openssl arguments






share|improve this question









New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 2 days ago









G-Man

12.2k92961




12.2k92961






New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 days ago









Jack Brown

13




13




New contributor




Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Jack Brown is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • What do you want the script to do with the argument?
    – Scott
    2 days ago










  • Same as in test1.sh, pass it to ls -l.
    – Jack Brown
    2 days ago








  • 1




    There's no ls -l in test2.sh
    – muru
    2 days ago






  • 1




    @muru There is, inside the encrypted script in test2.sh.
    – Kusalananda
    2 days ago


















  • What do you want the script to do with the argument?
    – Scott
    2 days ago










  • Same as in test1.sh, pass it to ls -l.
    – Jack Brown
    2 days ago








  • 1




    There's no ls -l in test2.sh
    – muru
    2 days ago






  • 1




    @muru There is, inside the encrypted script in test2.sh.
    – Kusalananda
    2 days ago
















What do you want the script to do with the argument?
– Scott
2 days ago




What do you want the script to do with the argument?
– Scott
2 days ago












Same as in test1.sh, pass it to ls -l.
– Jack Brown
2 days ago






Same as in test1.sh, pass it to ls -l.
– Jack Brown
2 days ago






1




1




There's no ls -l in test2.sh
– muru
2 days ago




There's no ls -l in test2.sh
– muru
2 days ago




1




1




@muru There is, inside the encrypted script in test2.sh.
– Kusalananda
2 days ago




@muru There is, inside the encrypted script in test2.sh.
– Kusalananda
2 days ago










2 Answers
2






active

oldest

votes

















up vote
0
down vote



accepted










This script will ask for a password, decrypt the encrypted script and run it with the first command line option passed to the main script:



#!/bin/bash

bash <(
openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe'
) "$1"


This does not use the #!-line of the decrypted script but assumes it will run okay under bash (and that it is always decrypted successfully). The decrypt script is passed to a bash interpreter by means of a process substitution on the openssl invocation, along with the first command line argument.



To write the decrypted script to disk, run it only if it was decrypted properly (using its intended interpreter), and then delete it:



#!/bin/bash

tmpscript=$(mktemp)
trap 'rm -f "$tmpscript"' EXIT

if ! openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe' >$tmpscript
then
exit 1
fi

chmod +x "$tmpscript"
"$tmpscript" "$1"


Would you want to pass all the command line parameters of the main script to the decrypted script, you should change "$1" in the above examples to "$@". The double quotes are important as they ensure that the individual arguments are passed without getting split on whitespaces and without undergoing filename globbing.






share|improve this answer























  • Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
    – Jack Brown
    2 days ago


















up vote
-1
down vote













You had it in an earlier version of the question — pass a -s option to sh:



echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe" | openssl enc -base64 -d -aes-256-cbc | sh -s "$1"


This tells the shell to read commands from the standard input,
while accepting arguments on its command line (after the -s)
as positional parameters for the script code coming from the standard input. 
Of course shell variables should always be quoted,
unless you have a good reason not to,
and it's probably more useful in the long run
to pass "@" (all the arguments) to the shell.



So it would also be wise to quote all references
to shell variables in test1.sh; e.g.,



ls -l "$1"


The first solution (presented above) seems to work well
for "normal" arguments. 
But, to handle the case of arguments that begin with -,
it's better to do sh -s -- "$1" (or "$@"). 
E.g.,



#!/bin/sh
code="U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"
echo "$code" | openssl enc -base64 -d -aes-256-cbc | sh -s -- "$@"


(where I put the encrypted script into a variable
just to make the command line shorter,
so it would fit into the Super User display column).






share|improve this answer























  • Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
    – Kusalananda
    2 days ago












  • @Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
    – G-Man
    2 days ago










  • The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
    – Kusalananda
    2 days ago










  • Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
    – Jack Brown
    2 days ago










  • Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
    – Jack Brown
    2 days ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});


}
});






Jack Brown is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483117%2fcalling-sh-with-script-on-stdin-and-passing-command-line-arguments%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted










This script will ask for a password, decrypt the encrypted script and run it with the first command line option passed to the main script:



#!/bin/bash

bash <(
openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe'
) "$1"


This does not use the #!-line of the decrypted script but assumes it will run okay under bash (and that it is always decrypted successfully). The decrypt script is passed to a bash interpreter by means of a process substitution on the openssl invocation, along with the first command line argument.



To write the decrypted script to disk, run it only if it was decrypted properly (using its intended interpreter), and then delete it:



#!/bin/bash

tmpscript=$(mktemp)
trap 'rm -f "$tmpscript"' EXIT

if ! openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe' >$tmpscript
then
exit 1
fi

chmod +x "$tmpscript"
"$tmpscript" "$1"


Would you want to pass all the command line parameters of the main script to the decrypted script, you should change "$1" in the above examples to "$@". The double quotes are important as they ensure that the individual arguments are passed without getting split on whitespaces and without undergoing filename globbing.






share|improve this answer























  • Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
    – Jack Brown
    2 days ago















up vote
0
down vote



accepted










This script will ask for a password, decrypt the encrypted script and run it with the first command line option passed to the main script:



#!/bin/bash

bash <(
openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe'
) "$1"


This does not use the #!-line of the decrypted script but assumes it will run okay under bash (and that it is always decrypted successfully). The decrypt script is passed to a bash interpreter by means of a process substitution on the openssl invocation, along with the first command line argument.



To write the decrypted script to disk, run it only if it was decrypted properly (using its intended interpreter), and then delete it:



#!/bin/bash

tmpscript=$(mktemp)
trap 'rm -f "$tmpscript"' EXIT

if ! openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe' >$tmpscript
then
exit 1
fi

chmod +x "$tmpscript"
"$tmpscript" "$1"


Would you want to pass all the command line parameters of the main script to the decrypted script, you should change "$1" in the above examples to "$@". The double quotes are important as they ensure that the individual arguments are passed without getting split on whitespaces and without undergoing filename globbing.






share|improve this answer























  • Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
    – Jack Brown
    2 days ago













up vote
0
down vote



accepted







up vote
0
down vote



accepted






This script will ask for a password, decrypt the encrypted script and run it with the first command line option passed to the main script:



#!/bin/bash

bash <(
openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe'
) "$1"


This does not use the #!-line of the decrypted script but assumes it will run okay under bash (and that it is always decrypted successfully). The decrypt script is passed to a bash interpreter by means of a process substitution on the openssl invocation, along with the first command line argument.



To write the decrypted script to disk, run it only if it was decrypted properly (using its intended interpreter), and then delete it:



#!/bin/bash

tmpscript=$(mktemp)
trap 'rm -f "$tmpscript"' EXIT

if ! openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe' >$tmpscript
then
exit 1
fi

chmod +x "$tmpscript"
"$tmpscript" "$1"


Would you want to pass all the command line parameters of the main script to the decrypted script, you should change "$1" in the above examples to "$@". The double quotes are important as they ensure that the individual arguments are passed without getting split on whitespaces and without undergoing filename globbing.






share|improve this answer














This script will ask for a password, decrypt the encrypted script and run it with the first command line option passed to the main script:



#!/bin/bash

bash <(
openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe'
) "$1"


This does not use the #!-line of the decrypted script but assumes it will run okay under bash (and that it is always decrypted successfully). The decrypt script is passed to a bash interpreter by means of a process substitution on the openssl invocation, along with the first command line argument.



To write the decrypted script to disk, run it only if it was decrypted properly (using its intended interpreter), and then delete it:



#!/bin/bash

tmpscript=$(mktemp)
trap 'rm -f "$tmpscript"' EXIT

if ! openssl enc -base64 -d -aes-256-cbc <<<'U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe' >$tmpscript
then
exit 1
fi

chmod +x "$tmpscript"
"$tmpscript" "$1"


Would you want to pass all the command line parameters of the main script to the decrypted script, you should change "$1" in the above examples to "$@". The double quotes are important as they ensure that the individual arguments are passed without getting split on whitespaces and without undergoing filename globbing.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 days ago

























answered 2 days ago









Kusalananda

116k15218352




116k15218352












  • Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
    – Jack Brown
    2 days ago


















  • Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
    – Jack Brown
    2 days ago
















Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
– Jack Brown
2 days ago




Thanks, the 1st works also with my mysql script where command line arguments are in the middle.
– Jack Brown
2 days ago












up vote
-1
down vote













You had it in an earlier version of the question — pass a -s option to sh:



echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe" | openssl enc -base64 -d -aes-256-cbc | sh -s "$1"


This tells the shell to read commands from the standard input,
while accepting arguments on its command line (after the -s)
as positional parameters for the script code coming from the standard input. 
Of course shell variables should always be quoted,
unless you have a good reason not to,
and it's probably more useful in the long run
to pass "@" (all the arguments) to the shell.



So it would also be wise to quote all references
to shell variables in test1.sh; e.g.,



ls -l "$1"


The first solution (presented above) seems to work well
for "normal" arguments. 
But, to handle the case of arguments that begin with -,
it's better to do sh -s -- "$1" (or "$@"). 
E.g.,



#!/bin/sh
code="U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"
echo "$code" | openssl enc -base64 -d -aes-256-cbc | sh -s -- "$@"


(where I put the encrypted script into a variable
just to make the command line shorter,
so it would fit into the Super User display column).






share|improve this answer























  • Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
    – Kusalananda
    2 days ago












  • @Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
    – G-Man
    2 days ago










  • The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
    – Kusalananda
    2 days ago










  • Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
    – Jack Brown
    2 days ago










  • Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
    – Jack Brown
    2 days ago















up vote
-1
down vote













You had it in an earlier version of the question — pass a -s option to sh:



echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe" | openssl enc -base64 -d -aes-256-cbc | sh -s "$1"


This tells the shell to read commands from the standard input,
while accepting arguments on its command line (after the -s)
as positional parameters for the script code coming from the standard input. 
Of course shell variables should always be quoted,
unless you have a good reason not to,
and it's probably more useful in the long run
to pass "@" (all the arguments) to the shell.



So it would also be wise to quote all references
to shell variables in test1.sh; e.g.,



ls -l "$1"


The first solution (presented above) seems to work well
for "normal" arguments. 
But, to handle the case of arguments that begin with -,
it's better to do sh -s -- "$1" (or "$@"). 
E.g.,



#!/bin/sh
code="U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"
echo "$code" | openssl enc -base64 -d -aes-256-cbc | sh -s -- "$@"


(where I put the encrypted script into a variable
just to make the command line shorter,
so it would fit into the Super User display column).






share|improve this answer























  • Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
    – Kusalananda
    2 days ago












  • @Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
    – G-Man
    2 days ago










  • The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
    – Kusalananda
    2 days ago










  • Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
    – Jack Brown
    2 days ago










  • Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
    – Jack Brown
    2 days ago













up vote
-1
down vote










up vote
-1
down vote









You had it in an earlier version of the question — pass a -s option to sh:



echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe" | openssl enc -base64 -d -aes-256-cbc | sh -s "$1"


This tells the shell to read commands from the standard input,
while accepting arguments on its command line (after the -s)
as positional parameters for the script code coming from the standard input. 
Of course shell variables should always be quoted,
unless you have a good reason not to,
and it's probably more useful in the long run
to pass "@" (all the arguments) to the shell.



So it would also be wise to quote all references
to shell variables in test1.sh; e.g.,



ls -l "$1"


The first solution (presented above) seems to work well
for "normal" arguments. 
But, to handle the case of arguments that begin with -,
it's better to do sh -s -- "$1" (or "$@"). 
E.g.,



#!/bin/sh
code="U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"
echo "$code" | openssl enc -base64 -d -aes-256-cbc | sh -s -- "$@"


(where I put the encrypted script into a variable
just to make the command line shorter,
so it would fit into the Super User display column).






share|improve this answer














You had it in an earlier version of the question — pass a -s option to sh:



echo "U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe" | openssl enc -base64 -d -aes-256-cbc | sh -s "$1"


This tells the shell to read commands from the standard input,
while accepting arguments on its command line (after the -s)
as positional parameters for the script code coming from the standard input. 
Of course shell variables should always be quoted,
unless you have a good reason not to,
and it's probably more useful in the long run
to pass "@" (all the arguments) to the shell.



So it would also be wise to quote all references
to shell variables in test1.sh; e.g.,



ls -l "$1"


The first solution (presented above) seems to work well
for "normal" arguments. 
But, to handle the case of arguments that begin with -,
it's better to do sh -s -- "$1" (or "$@"). 
E.g.,



#!/bin/sh
code="U2FsdGVkX1/m01Eg0CvZ7DiBi5Nf81+JrCWfKIDI9WtbkTZIVLhZskkKIioVfbSe"
echo "$code" | openssl enc -base64 -d -aes-256-cbc | sh -s -- "$@"


(where I put the encrypted script into a variable
just to make the command line shorter,
so it would fit into the Super User display column).







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 days ago

























answered 2 days ago









G-Man

12.2k92961




12.2k92961












  • Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
    – Kusalananda
    2 days ago












  • @Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
    – G-Man
    2 days ago










  • The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
    – Kusalananda
    2 days ago










  • Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
    – Jack Brown
    2 days ago










  • Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
    – Jack Brown
    2 days ago


















  • Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
    – Kusalananda
    2 days ago












  • @Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
    – G-Man
    2 days ago










  • The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
    – Kusalananda
    2 days ago










  • Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
    – Jack Brown
    2 days ago










  • Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
    – Jack Brown
    2 days ago
















Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
– Kusalananda
2 days ago






Using bash -s or sh -s may confuse things in the script that uses read. Also, it would ignore the interpreter of the embedded script (which would matter if it was later switched out for something written in another language).
– Kusalananda
2 days ago














@Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
– G-Man
2 days ago




@Kusalananda: (1) Interesting.  Does your answer do better? (2) Your answer does the same.
– G-Man
2 days ago












The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
– Kusalananda
2 days ago




The first part of my answer ignores the hashbang, but the second one doesn't. I never pass the decrypted script as data on stdin, so standard input will behave as expected.
– Kusalananda
2 days ago












Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
– Jack Brown
2 days ago




Works. Thank you. I realised that I need to provide wildcard using * even to my original script. Example test1.sh cat* would show only one file, while test1.sh cat* shows all cat* files.
– Jack Brown
2 days ago












Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
– Jack Brown
2 days ago




Yes, I had -s in my original question. Somehow I edited it many times, it didn't work anyway. It is indeed difficult to figure out that missing part -- "$@" at the end, still is.
– Jack Brown
2 days ago










Jack Brown is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















Jack Brown is a new contributor. Be nice, and check out our Code of Conduct.













Jack Brown is a new contributor. Be nice, and check out our Code of Conduct.












Jack Brown is a new contributor. Be nice, and check out our Code of Conduct.















 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f483117%2fcalling-sh-with-script-on-stdin-and-passing-command-line-arguments%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Entries order in /etc/network/interfaces

新発田市

Grub takes very long (several minutes) to open Menu (in Multi-Boot-System)