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













0















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 command


  • Forward command line arguments to the wrapped command


  • Forward stdout and stderr of the wrapped command to the caller


  • Forward 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.










share|improve this 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. 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
















0















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 command


  • Forward command line arguments to the wrapped command


  • Forward stdout and stderr of the wrapped command to the caller


  • Forward 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.










share|improve this 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. 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














0












0








0


1






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 command


  • Forward command line arguments to the wrapped command


  • Forward stdout and stderr of the wrapped command to the caller


  • Forward 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.










share|improve this question
















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 command


  • Forward command line arguments to the wrapped command


  • Forward stdout and stderr of the wrapped command to the caller


  • Forward 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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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. 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













  • 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








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











1 Answer
1






active

oldest

votes


















0














I think you're looking for expect.



Related question: Shell Script for logging into a ssh server






share|improve this answer








New contributor




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




















  • 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












  • 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


















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I think you're looking for expect.



Related question: Shell Script for logging into a ssh server






share|improve this answer








New contributor




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




















  • 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












  • 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
















0














I think you're looking for expect.



Related question: Shell Script for logging into a ssh server






share|improve this answer








New contributor




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




















  • 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












  • 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














0












0








0







I think you're looking for expect.



Related question: Shell Script for logging into a ssh server






share|improve this answer








New contributor




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










I think you're looking for expect.



Related question: Shell Script for logging into a ssh server







share|improve this answer








New contributor




JShorthouse 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 answer



share|improve this answer






New contributor




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









answered yesterday









JShorthouseJShorthouse

50728




50728




New contributor




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





New contributor





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






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












  • 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












  • 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












  • 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




-bash, command-line, shell-script

Popular posts from this blog

Frič See also Navigation menuinternal link

Identify plant with long narrow paired leaves and reddish stems Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?What is this plant with long sharp leaves? Is it a weed?What is this 3ft high, stalky plant, with mid sized narrow leaves?What is this young shrub with opposite ovate, crenate leaves and reddish stems?What is this plant with large broad serrated leaves?Identify this upright branching weed with long leaves and reddish stemsPlease help me identify this bulbous plant with long, broad leaves and white flowersWhat is this small annual with narrow gray/green leaves and rust colored daisy-type flowers?What is this chilli plant?Does anyone know what type of chilli plant this is?Help identify this plant

fontconfig warning: “/etc/fonts/fonts.conf”, line 100: unknown “element blank” The 2019 Stack Overflow Developer Survey Results Are In“tar: unrecognized option --warning” during 'apt-get install'How to fix Fontconfig errorHow do I figure out which font file is chosen for a system generic font alias?Why are some apt-get-installed fonts being ignored by fc-list, xfontsel, etc?Reload settings in /etc/fonts/conf.dTaking 30 seconds longer to boot after upgrade from jessie to stretchHow to match multiple font names with a single <match> element?Adding a custom font to fontconfigRemoving fonts from fontconfig <match> resultsBroken fonts after upgrading Firefox ESR to latest Firefox