Timeline for Why does `read` stop the function?
Current License: CC BY-SA 4.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 2, 2025 at 8:33 | comment | added | oditynet | test1() { ( set +m # Disable job control .... DEBUG trap → Command 1 → DEBUG trap → read | |
| Jan 29, 2025 at 13:33 | comment | added | cementblocks |
I've been able to reproduce in docker using image bash:5.2.15 in both architectures on my Macbook. I'm not able to reproduce in WSL on my home computer. I can't reproduce in the latest bash docker image 5.2.37(1). I've updated my installed version of bash, and I'll just move on. What's the right procedure here, just close the question?
|
|
| Jan 28, 2025 at 18:37 | comment | added | John Bollinger |
Since you seem confident that iterm2 is an important contributor to the issue, I have added iterm2 and macos tags.
|
|
| Jan 28, 2025 at 18:36 | history | edited | John Bollinger |
edited tags
|
|
| Jan 28, 2025 at 18:33 | comment | added | John Bollinger |
If the debug trap and extdebug option you edited into the question are what you mean by "iterm2 integration" then nope. Adding those does not cause the behavior you describe to manifest for me in my environment (which, however, is not iterm2 or even Mac). Nor do I expect them to do. They do cause my shell to report a number of traps, however, so perhaps you have a debug trap registered that does something weird (unlike the one you have presented).
|
|
| Jan 28, 2025 at 17:26 | comment | added | Charles Duffy |
How would read work in the background without taking control of the terminal? For a background task this is normal and expected; the only open question is why your code is being considered a background task.
|
|
| Jan 28, 2025 at 17:09 | comment | added | cementblocks |
I've determined the what the iterm2 shell integration does that causes this issue and edited the question to include it. I don't understand why two commands is different than one command before the read.
|
|
| Jan 28, 2025 at 17:07 | history | edited | cementblocks | CC BY-SA 4.0 |
Add additional setup to reproduce the behavior
|
| Jan 28, 2025 at 15:46 | comment | added | cementblocks |
I've tracked this down to being caused by the iterm2 shell integration. I'll look later to see if I can figure out more specifically than that.
|
|
| Jan 27, 2025 at 15:23 | review | Close votes | |||
| Jan 31, 2025 at 0:01 | |||||
| Jan 27, 2025 at 15:06 | comment | added | John Bollinger | Although I do not dispute that you observe the behavior described, it is not an expected behavior, and no one else seems to be able to reproduce it. I conclude that the issue is peculiar to your particular build or execution environment. I don't see any likelihood that we're going to be able to write an acceptable answer, so I'm voting to close as not reproducible. | |
| Jan 26, 2025 at 11:52 | comment | added | Arkadiusz Drabczyk |
Can you reproduce the behavior in interactive shell using docker run --rm -it bash?
|
|
| Jan 26, 2025 at 1:04 | comment | added | cementblocks | @Arkadisuz Any two commands (like actual executables not bash builtins) will trigger this behavour. two ls or two touch (they don't have to be the same), etc. If I put the function and function call into a script file then the behavior is not reproduced. It only happens when I'm using the shell interactively. | |
| Jan 26, 2025 at 0:59 | comment | added | cementblocks | I expect read in this case to prompt the user for input . The behavior is as if I had pressed ctrl+z. If I run "fg 1" then the function continues. | |
| Jan 25, 2025 at 12:19 | comment | added | Arkadiusz Drabczyk |
Do you press Control-z? Show output of type -a touch rm. What happens if you don't run the body of the function in a subshell?
|
|
| Jan 25, 2025 at 11:54 | comment | added | Ed Morton | Can't reproduce with bash 5.2.21. | |
| Jan 24, 2025 at 22:05 | comment | added | Diego Torres Milano | "If I only have one command before the read then the function executes as expected" what's expected ? | |
| Jan 24, 2025 at 20:36 | comment | added | shellter |
I essentially agree with you, but I would just like the O.P. to confirm they're understanding of how read is meant to work. For me, it's not clear from the provided example. Good luck to all!
|
|
| Jan 24, 2025 at 20:32 | comment | added | John Bollinger |
@shellter, I don't think you're quite tracking what the OP is trying to describe, as judged by the output they present. read may block, yes, but what's actually shown appears to be it running in a background job that gets stopped in the SIGTTIN or maybe SIGSTOP sense. I don't expect such behavior from the OP's code, and I don't reproduce it any more than you do, but I don't think the OP misunderstands the behavior of read.
|
|
| Jan 24, 2025 at 19:46 | comment | added | Gordon Davisson |
Do you also have an alias defined for test1? What does type -a test1 show
|
|
| Jan 24, 2025 at 19:45 | comment | added | shellter |
Sorry, but its not clear to me that you understand read is intended to "stop the job" until the user at least presses the enter key and optionally enters some string that will be assigned to the named variable (in this case anything). I believe you could also feed input via from a piped process or redirection of stdin. I pasted your exact test1 function to cmd line, and it worked as I expected. If you have further wrapping code, you may need to extend your minimum reproducible example. (+1 for starting with that!). Good luck.
|
|
| Jan 24, 2025 at 19:10 | comment | added | John Bollinger | I'm still somewhat incredulous about the behavior you describe, but if that's indeed reproducible for you then it would be community-minded to file a bug report. | |
| Jan 24, 2025 at 19:01 | comment | added | John Bollinger | You can also specify environment variables on the (each) command line for the commands executed by the function. | |
| Jan 24, 2025 at 17:45 | comment | added | pjh |
You can use local -x to create a local variable that is exported.
|
|
| Jan 24, 2025 at 16:46 | comment | added | cementblocks |
TIL local will prevent export from exporting a variable.
|
|
| Jan 24, 2025 at 16:39 | comment | added | John Bollinger |
A subshell is a pretty heavy tool for namespacing. Declaring variables local is the "other means" I had in mind for that particular objective. Subshells do provide isolation for other aspects of the execution environment, so there might still be a reasonable use case there, but it depends on what exactly you need to isolate.
|
|
| Jan 24, 2025 at 15:53 | comment | added | Cyrus |
To keep variable local use local within a function: local anything
|
|
| Jan 24, 2025 at 15:29 | comment | added | cementblocks | The big picture use case for the subshell is to keep variables from being exported. The actual use case is longer and there are calls to other bash functions that export variables. This function wants to use the variables from these functions but not ultimately export them. Thus the subshell. | |
| Jan 24, 2025 at 14:50 | comment | added | John Bollinger | To the extent that the code presented is sufficient for you to reproduce the issue in your Bash, I would be inclined to guess that it is related to putting all the work inside a subshell. I don't see what purpose is served by doing so in the function presented, that could not be better addressed by other means. | |
| Jan 24, 2025 at 14:46 | comment | added | John Bollinger | I do not reproduce the issue with the code presented, though I am running it in an earlier Bash. And I don't expect Bash or a POSIX shell to run any part of that command in the background, which your output appears to show is happening. | |
| Jan 24, 2025 at 13:48 | history | asked | cementblocks | CC BY-SA 4.0 |