Timeline for How can a Bash script tell how it was run?
Current License: CC BY-SA 3.0
32 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 20, 2014 at 11:44 | vote | accept | Aescula | ||
| Oct 20, 2014 at 11:07 | comment | added | Aescula | @Gilles I don't want to emulate it because it asks me for input every time. It streamlines a command, but it's a find. I don't want to find the same regex each time. Since I have narrowed down the problem to being the notifications, this is honestly less of an issue. If it becomes more of a problem I will open a new question. Thank you all! | |
| Oct 19, 2014 at 13:20 | comment | added | goldilocks | Aescula, I've added an idea to the bottom if your problem is specifically to do with invoking via point and click in a GUI. @Gilles Thanks for the comments, I've added a further caveat about that section of the "Advanced Guide". | |
| Oct 19, 2014 at 13:19 | history | edited | goldilocks | CC BY-SA 3.0 |
added 691 characters in body
|
| Oct 19, 2014 at 10:12 | comment | added | Gilles 'SO- stop being evil' | @Aescula This answer does what you requested in the question. If your notification mechanism doesn't work, you may want to ask another question, where you describe the notification mechanism that you used. But why don't you just start a terminal emulator and run the script in it? | |
| Oct 19, 2014 at 10:10 | comment | added | Gilles 'SO- stop being evil' |
@DanielAmaya No, you're misreading the man page, because you're confusing interactive shell with shell running in a terminal. A script (executed as a standalone program, through #!/bin/bash) is never interactive, even if it's running in a terminal. The remark about PS1 is admittedly misleading: bash sets it in an interactive shell, but it can also be set in a non-interactive shell, so it isn't a reliable test.
|
|
| Oct 19, 2014 at 0:38 | comment | added | Aescula | This as written SEEMS to work... But the strange thing is, I'm not getting the notifications to work when I run it from Nautilus. Either way. The cursor turns into the "working" thing and then back, nothing happens. | |
| Oct 18, 2014 at 22:38 | comment | added | Franz Kafka | @Gilles, continuing on: "When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists." So, in essence it would seem that both you and mikeserv disagree with the bash man page on this one. | |
| Oct 18, 2014 at 22:37 | comment | added | Franz Kafka | @Gilles, Actually, no I think I will nitpick on this some more. "An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state. The following paragraphs describe how bash executes its startup files." | |
| Oct 18, 2014 at 22:30 | comment | added | Franz Kafka |
Gilles, actually I will agree with you on this, and I think given the question, the best answer to it would have to be the one that is most downvoted here (testing for i in $-). Why? It's pretty clear that OP does not want to be able to double-click the script in Nautilus, and would rather it be run in the terminal (so that they can interact with it). However, if OP decides to redirect input for some reason at a later time, then the script breaks.
|
|
| Oct 18, 2014 at 20:39 | comment | added | Gilles 'SO- stop being evil' |
As for the -p bit, it contradicts the comment above that mentions a socket, for which the test would be -S. But I don't know what John Lange is trying to do there: if stdin isn't a terminal over SSH, it means that the script is not executed interactively, in which case it probably shouldn't do whatever it likes to do in a terminal, and in particular it shouldn't try to perform any user interaction.
|
|
| Oct 18, 2014 at 20:37 | comment | added | Gilles 'SO- stop being evil' |
That section from the Advanced Bash-Scripting Guide has several errors. PS1 is not a reliable test to tell whether the shell is interactive. “If a script needs to test whether it is running in an interactive shell” is also confusing: it should be if some code needs to test — a script is usually not running in an interactive shell (but it can be, if it's sourced). Testing for i in $- is the correct way to test if the shell is interactive. Testing -t 0 or -t 2 is the correct way to tell if the script is running in a terminal, which is different from being interactive.
|
|
| Oct 18, 2014 at 20:31 | comment | added | Gilles 'SO- stop being evil' |
@goldilocks Daniel's answer is wrong, plain and simple. PS1 is often set in a shell that isn't interactive, because people often set it in .profile or /etc/profile.
|
|
| Oct 18, 2014 at 18:49 | comment | added | goldilocks |
@DanielAmaya The Q is tagged bash. Pragmatically, yours is perhaps the better test (+1) but not perfect; I wanted to post this because there is something canonical about it (considering the specifics of the question) and its use value for people who may find their way here.
|
|
| Oct 18, 2014 at 18:43 | comment | added | goldilocks | @JonathanLeffler Thx -- replaced with double squares. | |
| Oct 18, 2014 at 18:42 | history | edited | goldilocks | CC BY-SA 3.0 |
added 2 characters in body
|
| Oct 18, 2014 at 18:25 | comment | added | mikeserv |
@DanielAmaya - fair enough. Try running: printf %b\\n 'PS1="this is an interactive shell\n"' '[ -t 0 ] || [ -t 1 ] || exit' | bash -i 2>&1 | sed '$a\and it is not connected to a terminal'
|
|
| Oct 18, 2014 at 18:14 | comment | added | Franz Kafka | @mikeserv, I think it's as simple as providing an example using bash that proves mine and xae's answers are not reliable (as you've stated). | |
| Oct 18, 2014 at 18:11 | comment | added | mikeserv |
@DanielAmaya - bash does the same as most modern shells - it detects automatically if it should start interactive based on whether its i/o is connected to a terminal. It is forced interactive with -i. Testing for an interactive shell is not the question - the question is testing for connection to a terminal.
|
|
| Oct 18, 2014 at 18:08 | comment | added | Franz Kafka | @mikeserv, and yet this question relates to bash, and from bash's very own man page we see the answer to this question being the two answers you've objected to here. Your objections are not based on bash, but rather sh. So, I figure if we can throw any shell out there, we may as well throw csh into the mix. The point being, none of these answers are reliable, as I've stated above. | |
| Oct 18, 2014 at 18:06 | comment | added | mikeserv |
@DanielAmaya - very true. csh doesn't handle a lot of the in/out stuff inherited from the traditional Bourne style shells. On the other hand, the tradtional Bourne-style shells didn't handle the history and job control offered in csh. general consensus was eventually found with ksh - and that is why it is the basis for the POSIX sh standard.
|
|
| Oct 18, 2014 at 17:56 | comment | added | Franz Kafka | This does not work in csh. | |
| Oct 18, 2014 at 17:44 | comment | added | chepner |
@JonathanLeffler Right; that should produce a syntax error, since the shell operator || is seen before the required final ] argument to [.
|
|
| Oct 18, 2014 at 17:34 | comment | added | Jonathan Leffler |
@chepner: agreed, but the context is that the -p is after the || operator that separates commands.
|
|
| Oct 18, 2014 at 16:42 | comment | added | chepner |
-p is a POSIX-specified primary for the test command.
|
|
| Oct 18, 2014 at 16:40 | comment | added | chepner |
Also, whether or not /dev/stdin exists in the file system depends on the operating system.
|
|
| Oct 18, 2014 at 16:14 | comment | added | Jonathan Leffler |
Are you sure about the use of || within [ … ] like that? If you use [[ … ]] then it would be fine, but normally the || is used to separate commands, and [ -t 0 is an incorrect invocation of [ because its last ] is missing. There typically isn't a command -p either. I agree with testing for a terminal; that's probably the way to do it. It's just the syntax I'm concerned about.
|
|
| Oct 18, 2014 at 16:02 | comment | added | mikeserv | @DanielAmaya - if you redirect input then the script is not being run on a terminal. The question is how to detect if the script is being run on a terminal. | |
| Oct 18, 2014 at 15:54 | comment | added | Franz Kafka | And yet, if I ever want to redirect input to my script, the test now fails, whereas it doesn't with a test for $PS1 being not null. | |
| Oct 18, 2014 at 15:32 | history | edited | goldilocks | CC BY-SA 3.0 |
added 1 character in body
|
| Oct 18, 2014 at 15:26 | comment | added | mikeserv | this is the correct answer - it is also how POSIX says a shell should detect if it is interactive or not. | |
| Oct 18, 2014 at 12:19 | history | answered | goldilocks | CC BY-SA 3.0 |