Bash: Complete wrapper for command line programs [on hold]Shell Script for logging into a ssh serverWrapping an interactive process with Bash to inject into STDINGeneral specification for command line interfaceBash read command and stdin redirectionbash autocomplete not working, does not 'complete'What is the technical term for command line application environment programs?How to secure a sudo - powered scriptMemoize (cache) for command-line programs?Filter out command line options before passing to a programWhere shall we place the commands for parsing command line arguments in a script?Why is it uncommon for stdin inputs to have option-like inputs, while common for command line arguments?Wrapping an interactive process with Bash to inject into STDIN
Go Pregnant or Go Home
Would a high gravity rocky planet be guaranteed to have an atmosphere?
What is the intuitive meaning of having a linear relationship between the logs of two variables?
Sequence of Tenses: Translating the subjunctive
You cannot touch me, but I can touch you, who am I?
Purchasing a ticket for someone else in another country?
Is expanding the research of a group into machine learning as a PhD student risky?
How to write papers efficiently when English isn't my first language?
Detecting if an element is found inside a container
Class Action - which options I have?
Why didn't Theresa May consult with Parliament before negotiating a deal with the EU?
Term for the "extreme-extension" version of a straw man fallacy?
Type int? vs type int
How do I extract a value from a time formatted value in excel?
Why Were Madagascar and New Zealand Discovered So Late?
How to pronounce the slash sign
How can I get through very long and very dry, but also very useful technical documents when learning a new tool?
Closest Prime Number
What is the best translation for "slot" in the context of multiplayer video games?
Pole-zeros of a real-valued causal FIR system
Where does the Z80 processor start executing from?
How to be diplomatic in refusing to write code that breaches the privacy of our users
How do I find the solutions of the following equation?
Is HostGator storing my password in plaintext?
Bash: Complete wrapper for command line programs [on hold]
Shell Script for logging into a ssh serverWrapping an interactive process with Bash to inject into STDINGeneral specification for command line interfaceBash read command and stdin redirectionbash autocomplete not working, does not 'complete'What is the technical term for command line application environment programs?How to secure a sudo - powered scriptMemoize (cache) for command-line programs?Filter out command line options before passing to a programWhere shall we place the commands for parsing command line arguments in a script?Why is it uncommon for stdin inputs to have option-like inputs, while common for command line arguments?Wrapping an interactive process with Bash to inject into STDIN
Is it possible (and if, how) to write a complete wrapper for a generic command line program in bash.
With complete, I mean that it should behave with respect to the digestion of the different allowed forms of inputs and its outputs like the wrapped, unspecified, command line program itself.
In particular, it should forward all arguments specified at the command line and, if present, any input sent through stdin via a pipe.
I am not primarily thinking of input through signals (aka kill -s USR1
pid), albeit that would be interesting as well. Also, I may be overlooking other possible forms of communication that may be relevant, but these are not a priority either.
With respect to command line output and interactive input (read
) it should also show the same behavior as the wrapped program itself (but that seems to be largely the case 'by default' when invoking a command line program from within a bash script in the straight-forward way).
The background is that I have a program interacting with the input in some unknown way. Trying to replace it with a wrapper, I found that the interaction with its caller does not work anymore. The purpose of the wrapper is to modify one of the input arguments.
You may assume that the caller invokes the program (or the wrapper) via a shell or with exec
or a similar system call. That is, the caller does not in some way analyse the content of the original program to determine its behavior.
In summary, the required behavior of the wrapper is
Forward
stdin
to the wrapped commandForward command line arguments to the wrapped command
Forward
stdout
andstderr
of the wrapped command to the callerForward interactive input to the wrapped command if it reads
Since the last two should be 'default', and the second one pretty obvious ("$@"
) it seems that the challenge is mostly to forward stdin
properly, but it would also good to know what else should be considered.
bash shell-script command-line
put on hold as unclear what you're asking by Rui F Ribeiro, X Tian, roaima, G-Man, jimmij 20 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 1 more comment
Is it possible (and if, how) to write a complete wrapper for a generic command line program in bash.
With complete, I mean that it should behave with respect to the digestion of the different allowed forms of inputs and its outputs like the wrapped, unspecified, command line program itself.
In particular, it should forward all arguments specified at the command line and, if present, any input sent through stdin via a pipe.
I am not primarily thinking of input through signals (aka kill -s USR1
pid), albeit that would be interesting as well. Also, I may be overlooking other possible forms of communication that may be relevant, but these are not a priority either.
With respect to command line output and interactive input (read
) it should also show the same behavior as the wrapped program itself (but that seems to be largely the case 'by default' when invoking a command line program from within a bash script in the straight-forward way).
The background is that I have a program interacting with the input in some unknown way. Trying to replace it with a wrapper, I found that the interaction with its caller does not work anymore. The purpose of the wrapper is to modify one of the input arguments.
You may assume that the caller invokes the program (or the wrapper) via a shell or with exec
or a similar system call. That is, the caller does not in some way analyse the content of the original program to determine its behavior.
In summary, the required behavior of the wrapper is
Forward
stdin
to the wrapped commandForward command line arguments to the wrapped command
Forward
stdout
andstderr
of the wrapped command to the callerForward interactive input to the wrapped command if it reads
Since the last two should be 'default', and the second one pretty obvious ("$@"
) it seems that the challenge is mostly to forward stdin
properly, but it would also good to know what else should be considered.
bash shell-script command-line
put on hold as unclear what you're asking by Rui F Ribeiro, X Tian, roaima, G-Man, jimmij 20 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
1
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
@highsciguy Yes it is relevant. Ifexpect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.
– LL3
yesterday
|
show 1 more comment
Is it possible (and if, how) to write a complete wrapper for a generic command line program in bash.
With complete, I mean that it should behave with respect to the digestion of the different allowed forms of inputs and its outputs like the wrapped, unspecified, command line program itself.
In particular, it should forward all arguments specified at the command line and, if present, any input sent through stdin via a pipe.
I am not primarily thinking of input through signals (aka kill -s USR1
pid), albeit that would be interesting as well. Also, I may be overlooking other possible forms of communication that may be relevant, but these are not a priority either.
With respect to command line output and interactive input (read
) it should also show the same behavior as the wrapped program itself (but that seems to be largely the case 'by default' when invoking a command line program from within a bash script in the straight-forward way).
The background is that I have a program interacting with the input in some unknown way. Trying to replace it with a wrapper, I found that the interaction with its caller does not work anymore. The purpose of the wrapper is to modify one of the input arguments.
You may assume that the caller invokes the program (or the wrapper) via a shell or with exec
or a similar system call. That is, the caller does not in some way analyse the content of the original program to determine its behavior.
In summary, the required behavior of the wrapper is
Forward
stdin
to the wrapped commandForward command line arguments to the wrapped command
Forward
stdout
andstderr
of the wrapped command to the callerForward interactive input to the wrapped command if it reads
Since the last two should be 'default', and the second one pretty obvious ("$@"
) it seems that the challenge is mostly to forward stdin
properly, but it would also good to know what else should be considered.
bash shell-script command-line
Is it possible (and if, how) to write a complete wrapper for a generic command line program in bash.
With complete, I mean that it should behave with respect to the digestion of the different allowed forms of inputs and its outputs like the wrapped, unspecified, command line program itself.
In particular, it should forward all arguments specified at the command line and, if present, any input sent through stdin via a pipe.
I am not primarily thinking of input through signals (aka kill -s USR1
pid), albeit that would be interesting as well. Also, I may be overlooking other possible forms of communication that may be relevant, but these are not a priority either.
With respect to command line output and interactive input (read
) it should also show the same behavior as the wrapped program itself (but that seems to be largely the case 'by default' when invoking a command line program from within a bash script in the straight-forward way).
The background is that I have a program interacting with the input in some unknown way. Trying to replace it with a wrapper, I found that the interaction with its caller does not work anymore. The purpose of the wrapper is to modify one of the input arguments.
You may assume that the caller invokes the program (or the wrapper) via a shell or with exec
or a similar system call. That is, the caller does not in some way analyse the content of the original program to determine its behavior.
In summary, the required behavior of the wrapper is
Forward
stdin
to the wrapped commandForward command line arguments to the wrapped command
Forward
stdout
andstderr
of the wrapped command to the callerForward interactive input to the wrapped command if it reads
Since the last two should be 'default', and the second one pretty obvious ("$@"
) it seems that the challenge is mostly to forward stdin
properly, but it would also good to know what else should be considered.
bash shell-script command-line
bash shell-script command-line
edited yesterday
highsciguy
asked yesterday
highsciguyhighsciguy
99231121
99231121
put on hold as unclear what you're asking by Rui F Ribeiro, X Tian, roaima, G-Man, jimmij 20 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as unclear what you're asking by Rui F Ribeiro, X Tian, roaima, G-Man, jimmij 20 hours ago
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
1
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
@highsciguy Yes it is relevant. Ifexpect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.
– LL3
yesterday
|
show 1 more comment
1
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
@highsciguy Yes it is relevant. Ifexpect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.
– LL3
yesterday
1
1
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
@highsciguy Yes it is relevant. If
expect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.– LL3
yesterday
@highsciguy Yes it is relevant. If
expect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.– LL3
yesterday
|
show 1 more comment
1 Answer
1
active
oldest
votes
I think you're looking for expect.
Related question: Shell Script for logging into a ssh server
New contributor
Thanks, I am aware ofexpect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.
– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think you're looking for expect.
Related question: Shell Script for logging into a ssh server
New contributor
Thanks, I am aware ofexpect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.
– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
add a comment |
I think you're looking for expect.
Related question: Shell Script for logging into a ssh server
New contributor
Thanks, I am aware ofexpect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.
– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
add a comment |
I think you're looking for expect.
Related question: Shell Script for logging into a ssh server
New contributor
I think you're looking for expect.
Related question: Shell Script for logging into a ssh server
New contributor
New contributor
answered yesterday
JShorthouseJShorthouse
50728
50728
New contributor
New contributor
Thanks, I am aware ofexpect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.
– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
add a comment |
Thanks, I am aware ofexpect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.
– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
Thanks, I am aware of
expect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.– highsciguy
yesterday
Thanks, I am aware of
expect
, but, unless it has uses other than the one I am thinking of, it is not what I am looking for. My present understanding is that its prime purpose is to interact with a programs output in an automated fashion. My wrapper should have the default behavior of a bash script regarding the forwarding of outputs (stdout, stderr) and also interactive input. I am not interested in modifying or parsing these.– highsciguy
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
Ah ok, does this question sound similar to what you are trying to achieve? If I'm understanding you correctly then I was trying to solve a very similar problem a couple of days ago, and it can be done with expect.
– JShorthouse
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
This answer sounds more a comment
– Rui F Ribeiro
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
We try to avoid link-only answers here. Would you be able to summarise the important bits from the page that you link to in such a way that your answer becomes self contained?
– Kusalananda♦
yesterday
add a comment |
-bash, command-line, shell-script
1
I'm really sorry, but I haven't got a clue what you're actually asking. Maybe some code examples might help.
– roaima
yesterday
I want a wrapper implemented in bash. A script that sits in-between the caller and the program that the caller normally calls. The program and the caller are fixed (I cannot modify them) and the caller expects to interact with the program in a certain way. The wrapper should imitate that interface as good as possible such that it is transparent to the caller.
– highsciguy
yesterday
It can be possible as long as the wrapped program just reads from stdin and writes to stdout/stderr. I can elaborate a full answer for that. Signals handling can be possible too. But if instead the wrapped program expects its stdin/stdout to be a tty, (which is something more than mere interactivity), then I’m afraid you can’t emulate that in bash. Also, wrt other possible communication channels, is it possibly not the case that the caller program expects the called program to create eg sockets or some kind of IPC ?
– LL3
yesterday
I think you can ignore the possibility of a tty (its a relevant mention that this possibility exists). I didn't have time to look at the link posted by @JShorthouse below. Maybe its relevant.
– highsciguy
yesterday
@highsciguy Yes it is relevant. If
expect
is not appropriate for your case, then have a look also at my own answer in @JShorthouse 's question of two days ago. My answer there may hint you about a possible bash implementation of what you need. That was tailored to his case but can be adjusted for your case.– LL3
yesterday