How does this shebang that starts with a double hyphen (--) work?
I have found the following kind of shebang in the RosettaCode page:
--() { :; }; exec db2 -txf "$0"
It works for Db2, and a similar thing for Postgres. However, I do not understand the whole line.
I know the double dash is a comment in SQL, and after that it calls the Db2 executable with some parameters passing the file itself as file. But what about the parenthesis, the curly brakets, the colon and semi-colon, and how can replace a real shebang #! ?
https://rosettacode.org/wiki/Multiline_shebang#PostgreSQL
shell-script scripting sql shebang db2
add a comment |
I have found the following kind of shebang in the RosettaCode page:
--() { :; }; exec db2 -txf "$0"
It works for Db2, and a similar thing for Postgres. However, I do not understand the whole line.
I know the double dash is a comment in SQL, and after that it calls the Db2 executable with some parameters passing the file itself as file. But what about the parenthesis, the curly brakets, the colon and semi-colon, and how can replace a real shebang #! ?
https://rosettacode.org/wiki/Multiline_shebang#PostgreSQL
shell-script scripting sql shebang db2
add a comment |
I have found the following kind of shebang in the RosettaCode page:
--() { :; }; exec db2 -txf "$0"
It works for Db2, and a similar thing for Postgres. However, I do not understand the whole line.
I know the double dash is a comment in SQL, and after that it calls the Db2 executable with some parameters passing the file itself as file. But what about the parenthesis, the curly brakets, the colon and semi-colon, and how can replace a real shebang #! ?
https://rosettacode.org/wiki/Multiline_shebang#PostgreSQL
shell-script scripting sql shebang db2
I have found the following kind of shebang in the RosettaCode page:
--() { :; }; exec db2 -txf "$0"
It works for Db2, and a similar thing for Postgres. However, I do not understand the whole line.
I know the double dash is a comment in SQL, and after that it calls the Db2 executable with some parameters passing the file itself as file. But what about the parenthesis, the curly brakets, the colon and semi-colon, and how can replace a real shebang #! ?
https://rosettacode.org/wiki/Multiline_shebang#PostgreSQL
shell-script scripting sql shebang db2
shell-script scripting sql shebang db2
edited Dec 15 '18 at 2:09
muru
1
1
asked Dec 14 '18 at 21:47
AngocAAngocA
1959
1959
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Related: Which shell interpreter runs a script with no shebang?
The script does not have a shebang/hashbang/#!
line, simply because a double dash is not #!
.
However, the script will be executed by a shell (see above linked question and answers), and in that shell, if -
is a valid character in a function name, the line declares a shell function called --
that does nothing (well, it runs :
, which does nothing) and which is never called.
The function, in the more common multi-line notation (just to make it more obvious what it looks like, as its odd name kinda obscures the fact that it's in fact a function):
-- () {
:
}
The sole purpose of the function definition is to have a line that is valid in a shell script and at the same time a valid SQL command (a comment). This sort of code is called a polyglot.
After declaring the bogus shell function, the script, when executed by a shell script interpreter, uses exec
to replace the current shell with the process resulting from running db2 -txf "$0"
, which would be the same as using db2 -txf
on the pathname of the script from the command line.
This trick would probably not work reliably on systems where dash
or other ash
-based shells, yash
, the Bourne shell, ksh88
or ksh93
is used as /bin/sh
, as these shell do not accept functions whose name contains dashes.
Also related:
- Shell valid function name characters
- Will it be bad that a function or script name contains dash `-` instead of underline `_`?
I suppose the following would also work (not really tested):
--() { exec db2 -txf "$0"; }; --
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
add a comment |
As @Kusalananda has already said, that trick is broken and it won't work in all shells.
Here is my take at doing it portably:
--/.. 2>/dev/null; exec db2 -txf "$0"
The first command should fail even if a file/directory named --
exists in the current directory and any errors will be shut up by the 2>/dev/null
; the shell will then proceed with the second command, the exec
.
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returnsENOEXEC
if you try to. Try running the script understrace
to see what I mean.
– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script ifexec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)
– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if youexec()
it directly from something other than a shell. But what would that case be? You might want to run the script fromcron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell outdb2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.
– ilkkachu
Dec 15 '18 at 15:01
1
@kasperd I won't annoy you with docs and standards; just try it!echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
|
show 4 more comments
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',
autoActivateHeartbeat: false,
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
});
}
});
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%2funix.stackexchange.com%2fquestions%2f488068%2fhow-does-this-shebang-that-starts-with-a-double-hyphen-work%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
Related: Which shell interpreter runs a script with no shebang?
The script does not have a shebang/hashbang/#!
line, simply because a double dash is not #!
.
However, the script will be executed by a shell (see above linked question and answers), and in that shell, if -
is a valid character in a function name, the line declares a shell function called --
that does nothing (well, it runs :
, which does nothing) and which is never called.
The function, in the more common multi-line notation (just to make it more obvious what it looks like, as its odd name kinda obscures the fact that it's in fact a function):
-- () {
:
}
The sole purpose of the function definition is to have a line that is valid in a shell script and at the same time a valid SQL command (a comment). This sort of code is called a polyglot.
After declaring the bogus shell function, the script, when executed by a shell script interpreter, uses exec
to replace the current shell with the process resulting from running db2 -txf "$0"
, which would be the same as using db2 -txf
on the pathname of the script from the command line.
This trick would probably not work reliably on systems where dash
or other ash
-based shells, yash
, the Bourne shell, ksh88
or ksh93
is used as /bin/sh
, as these shell do not accept functions whose name contains dashes.
Also related:
- Shell valid function name characters
- Will it be bad that a function or script name contains dash `-` instead of underline `_`?
I suppose the following would also work (not really tested):
--() { exec db2 -txf "$0"; }; --
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
add a comment |
Related: Which shell interpreter runs a script with no shebang?
The script does not have a shebang/hashbang/#!
line, simply because a double dash is not #!
.
However, the script will be executed by a shell (see above linked question and answers), and in that shell, if -
is a valid character in a function name, the line declares a shell function called --
that does nothing (well, it runs :
, which does nothing) and which is never called.
The function, in the more common multi-line notation (just to make it more obvious what it looks like, as its odd name kinda obscures the fact that it's in fact a function):
-- () {
:
}
The sole purpose of the function definition is to have a line that is valid in a shell script and at the same time a valid SQL command (a comment). This sort of code is called a polyglot.
After declaring the bogus shell function, the script, when executed by a shell script interpreter, uses exec
to replace the current shell with the process resulting from running db2 -txf "$0"
, which would be the same as using db2 -txf
on the pathname of the script from the command line.
This trick would probably not work reliably on systems where dash
or other ash
-based shells, yash
, the Bourne shell, ksh88
or ksh93
is used as /bin/sh
, as these shell do not accept functions whose name contains dashes.
Also related:
- Shell valid function name characters
- Will it be bad that a function or script name contains dash `-` instead of underline `_`?
I suppose the following would also work (not really tested):
--() { exec db2 -txf "$0"; }; --
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
add a comment |
Related: Which shell interpreter runs a script with no shebang?
The script does not have a shebang/hashbang/#!
line, simply because a double dash is not #!
.
However, the script will be executed by a shell (see above linked question and answers), and in that shell, if -
is a valid character in a function name, the line declares a shell function called --
that does nothing (well, it runs :
, which does nothing) and which is never called.
The function, in the more common multi-line notation (just to make it more obvious what it looks like, as its odd name kinda obscures the fact that it's in fact a function):
-- () {
:
}
The sole purpose of the function definition is to have a line that is valid in a shell script and at the same time a valid SQL command (a comment). This sort of code is called a polyglot.
After declaring the bogus shell function, the script, when executed by a shell script interpreter, uses exec
to replace the current shell with the process resulting from running db2 -txf "$0"
, which would be the same as using db2 -txf
on the pathname of the script from the command line.
This trick would probably not work reliably on systems where dash
or other ash
-based shells, yash
, the Bourne shell, ksh88
or ksh93
is used as /bin/sh
, as these shell do not accept functions whose name contains dashes.
Also related:
- Shell valid function name characters
- Will it be bad that a function or script name contains dash `-` instead of underline `_`?
I suppose the following would also work (not really tested):
--() { exec db2 -txf "$0"; }; --
Related: Which shell interpreter runs a script with no shebang?
The script does not have a shebang/hashbang/#!
line, simply because a double dash is not #!
.
However, the script will be executed by a shell (see above linked question and answers), and in that shell, if -
is a valid character in a function name, the line declares a shell function called --
that does nothing (well, it runs :
, which does nothing) and which is never called.
The function, in the more common multi-line notation (just to make it more obvious what it looks like, as its odd name kinda obscures the fact that it's in fact a function):
-- () {
:
}
The sole purpose of the function definition is to have a line that is valid in a shell script and at the same time a valid SQL command (a comment). This sort of code is called a polyglot.
After declaring the bogus shell function, the script, when executed by a shell script interpreter, uses exec
to replace the current shell with the process resulting from running db2 -txf "$0"
, which would be the same as using db2 -txf
on the pathname of the script from the command line.
This trick would probably not work reliably on systems where dash
or other ash
-based shells, yash
, the Bourne shell, ksh88
or ksh93
is used as /bin/sh
, as these shell do not accept functions whose name contains dashes.
Also related:
- Shell valid function name characters
- Will it be bad that a function or script name contains dash `-` instead of underline `_`?
I suppose the following would also work (not really tested):
--() { exec db2 -txf "$0"; }; --
edited Dec 15 '18 at 15:29
answered Dec 14 '18 at 22:09
KusalanandaKusalananda
124k16234385
124k16234385
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
add a comment |
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
@ilkkachu Better now?
– Kusalananda
Dec 15 '18 at 15:30
1
1
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
oh yes! And thanks for reminding me what that sort of thing is called. :)
– ilkkachu
Dec 15 '18 at 15:34
add a comment |
As @Kusalananda has already said, that trick is broken and it won't work in all shells.
Here is my take at doing it portably:
--/.. 2>/dev/null; exec db2 -txf "$0"
The first command should fail even if a file/directory named --
exists in the current directory and any errors will be shut up by the 2>/dev/null
; the shell will then proceed with the second command, the exec
.
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returnsENOEXEC
if you try to. Try running the script understrace
to see what I mean.
– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script ifexec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)
– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if youexec()
it directly from something other than a shell. But what would that case be? You might want to run the script fromcron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell outdb2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.
– ilkkachu
Dec 15 '18 at 15:01
1
@kasperd I won't annoy you with docs and standards; just try it!echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
|
show 4 more comments
As @Kusalananda has already said, that trick is broken and it won't work in all shells.
Here is my take at doing it portably:
--/.. 2>/dev/null; exec db2 -txf "$0"
The first command should fail even if a file/directory named --
exists in the current directory and any errors will be shut up by the 2>/dev/null
; the shell will then proceed with the second command, the exec
.
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returnsENOEXEC
if you try to. Try running the script understrace
to see what I mean.
– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script ifexec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)
– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if youexec()
it directly from something other than a shell. But what would that case be? You might want to run the script fromcron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell outdb2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.
– ilkkachu
Dec 15 '18 at 15:01
1
@kasperd I won't annoy you with docs and standards; just try it!echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
|
show 4 more comments
As @Kusalananda has already said, that trick is broken and it won't work in all shells.
Here is my take at doing it portably:
--/.. 2>/dev/null; exec db2 -txf "$0"
The first command should fail even if a file/directory named --
exists in the current directory and any errors will be shut up by the 2>/dev/null
; the shell will then proceed with the second command, the exec
.
As @Kusalananda has already said, that trick is broken and it won't work in all shells.
Here is my take at doing it portably:
--/.. 2>/dev/null; exec db2 -txf "$0"
The first command should fail even if a file/directory named --
exists in the current directory and any errors will be shut up by the 2>/dev/null
; the shell will then proceed with the second command, the exec
.
edited Dec 14 '18 at 23:11
answered Dec 14 '18 at 22:31
Uncle BillyUncle Billy
3915
3915
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returnsENOEXEC
if you try to. Try running the script understrace
to see what I mean.
– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script ifexec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)
– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if youexec()
it directly from something other than a shell. But what would that case be? You might want to run the script fromcron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell outdb2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.
– ilkkachu
Dec 15 '18 at 15:01
1
@kasperd I won't annoy you with docs and standards; just try it!echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
|
show 4 more comments
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returnsENOEXEC
if you try to. Try running the script understrace
to see what I mean.
– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script ifexec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)
– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if youexec()
it directly from something other than a shell. But what would that case be? You might want to run the script fromcron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell outdb2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.
– ilkkachu
Dec 15 '18 at 15:01
1
@kasperd I won't annoy you with docs and standards; just try it!echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returns
ENOEXEC
if you try to. Try running the script under strace
to see what I mean.– kasperd
Dec 15 '18 at 13:40
It's still not really portable. It's not a valid script and you are still relying on the calling shell to work around the fact that the kernel will refuse to run the script and returns
ENOEXEC
if you try to. Try running the script under strace
to see what I mean.– kasperd
Dec 15 '18 at 13:40
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script if
exec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)– ilkkachu
Dec 15 '18 at 14:13
@kasperd, it should still be portable, the shell is supposed to run the script as a shell script if
exec()
doesn't work on it. "If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell shall execute a command equivalent to having a shell invoked with the command name as its first operand, ... " (see pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/…)– ilkkachu
Dec 15 '18 at 14:13
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@ilkkachu But scripts are not always executed from a shell. If you try to use the script in any other context where an executable would work it's going to fail. Moreover shells don't agree on which interpreter to use. So your script will now behave differently or fail altogether depending on which context it is being called from.
– kasperd
Dec 15 '18 at 14:28
@kasperd, well, sure, it won't work if you
exec()
it directly from something other than a shell. But what would that case be? You might want to run the script from cron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell out db2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.– ilkkachu
Dec 15 '18 at 15:01
@kasperd, well, sure, it won't work if you
exec()
it directly from something other than a shell. But what would that case be? You might want to run the script from cron
or such, but I think it runs everything through a shell anyway, and even if not, it's easy to just spell out db2 -txf /path/to/script
in that case, since you only need to do it once. Having the shorthand work is mostly useful on an interactive shell. But sure, a separate wrapper script might be more robust.– ilkkachu
Dec 15 '18 at 15:01
1
1
@kasperd I won't annoy you with docs and standards; just try it!
echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
@kasperd I won't annoy you with docs and standards; just try it!
echo 'int main(int c,char**a){execvp(a[1],a+1);}' | cc -include unistd.h -xc -; echo echo yeah > a.sh; chmod 755 a.sh; ./a.out ./a.sh; PATH=`pwd` ./a.out a.sh
– Uncle Billy
Dec 16 '18 at 0:00
|
show 4 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f488068%2fhow-does-this-shebang-that-starts-with-a-double-hyphen-work%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