Re: strange bash behavior
On Tue, 2013-09-03 at 20:01 -0400, William Hopkins wrote: On 09/03/13 at 03:45pm, Joe Pfeiffer wrote: Stephen Powell zlinux...@wowway.com writes: Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. Good point -- it is odd that it isn't giving the error message. The loop context is inherited by the subshell, so break thinks it is fine. It is only that it is totally meaningless to break there, since that signal cannot be captured by parent shell environment. This seems to be expected behavior.. I would say so. The list creates a second shell that is not reporting the error message back to the parent shell because the error was supposed to be of minor importance and not critical to the parent. The message is most likely sent to the subshell before it's killed remaining hidden from stdout. But you should check this out, I'm just saying it makes sense. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378331575.2974.13.camel@tagesuhu-pc
Re: strange bash behavior
On Mon, 02 Sep 2013 12:26:17 -0400 (EDT), Stephen Powell wrote: Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. I just tried this in both ash and dash. Neither one of them produce an error message when break is issued out of context. It simply executes as a no-op. (break is a shell built-in command, of course, not an external command.) So despite the fact that break is not producing an error message when one might expect it to, it is apparently exhibiting expected behavior in the sense that output is identical to what would occur with ash and dash. (Issue busybox ash to get ash. exit to exit, of course.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84639284.2989400.1378334667562.javamail.r...@md01.wow.synacor.com
Re: strange bash behavior
William Hopkins we.hopk...@gmail.com writes: On 09/03/13 at 03:45pm, Joe Pfeiffer wrote: Stephen Powell zlinux...@wowway.com writes: Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. Good point -- it is odd that it isn't giving the error message. The loop context is inherited by the subshell, so break thinks it is fine. It is only that it is totally meaningless to break there, since that signal cannot be captured by parent shell environment. How is the context passed to the subshell? And what signal? This seems to be expected behavior.. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1bd2oo7yqh@snowball.wb.pfeifferfamily.net
Re: strange bash behavior
David Guntner da...@guntner.com writes: Darac Marjal grabbed a keyboard and wrote: On Mon, Sep 02, 2013 at 08:06:17AM -0700, David Guntner wrote: Matej Kosik grabbed a keyboard and wrote: Hello, This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? What do you mean by appears in a subshell? From man 1 bash: (list) list is executed in a subshell environment (see COMMAND EXECU‐ TION ENVIRONMENT below). Variable assignments and builtin com‐ mands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list. Ok, I'm still not following you. What, exactly, is it that you are doing at your keyboard, in order to run it in this subshell? I'm assuming that in your main one you're just typing the expression and hitting enter. So what are you doing when the second example fails? Based on his post, he is putting 'break' in parentheses in the second case. This causes a new shell (the subshell) to be created, and the break command to be executed in that subshell. The subshell then exits. This is exactly the behavior I would expect: the break command isn't being executed by the same shell as your for-loop. The for-loop has no way of knowing that the subshell executed a break command (note that the break command is a shell built-in command -- it is interpreted and executed by the shell itself, no new process is created for it). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1br4d5mvmi@snowball.wb.pfeifferfamily.net
Re: strange bash behavior
Stephen Powell zlinux...@wowway.com writes: Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. Good point -- it is odd that it isn't giving the error message. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1bmwntmvfc@snowball.wb.pfeifferfamily.net
Re: strange bash behavior
On 09/02/13 at 08:29am, David Guntner wrote: Darac Marjal grabbed a keyboard and wrote: On Mon, Sep 02, 2013 at 08:06:17AM -0700, David Guntner wrote: Matej Kosik grabbed a keyboard and wrote: What do you mean by appears in a subshell? From man 1 bash: (list) list is executed in a subshell environment (see COMMAND EXECU‐ TION ENVIRONMENT below). Variable assignments and builtin com‐ mands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list. Ok, I'm still not following you. What, exactly, is it that you are doing at your keyboard, in order to run it in this subshell? I'm assuming that in your main one you're just typing the expression and hitting enter. So what are you doing when the second example fails? Respectfully, read the snippet from bash(1) he provided. Commands in parentheses are executed in a subshell. which is a second instance of bash with its own (inherited) working environment. If you're not a bash person, that's OK, but don't reply to bash questions (: -- Liam signature.asc Description: Digital signature
Re: strange bash behavior
On 09/03/13 at 03:45pm, Joe Pfeiffer wrote: Stephen Powell zlinux...@wowway.com writes: Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. Good point -- it is odd that it isn't giving the error message. The loop context is inherited by the subshell, so break thinks it is fine. It is only that it is totally meaningless to break there, since that signal cannot be captured by parent shell environment. This seems to be expected behavior.. -- Liam signature.asc Description: Digital signature
strange bash behavior
Hello, This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52245a1b.2030...@gmail.com
Re: strange bash behavior
Matej Kosik grabbed a keyboard and wrote: Hello, This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? What do you mean by appears in a subshell? --Dave smime.p7s Description: S/MIME Cryptographic Signature
Re: strange bash behavior
On Mon, Sep 02, 2013 at 08:06:17AM -0700, David Guntner wrote: Matej Kosik grabbed a keyboard and wrote: Hello, This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? What do you mean by appears in a subshell? From man 1 bash: (list) list is executed in a subshell environment (see COMMAND EXECU‐ TION ENVIRONMENT below). Variable assignments and builtin com‐ mands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list. signature.asc Description: Digital signature
Re: strange bash behavior
Darac Marjal grabbed a keyboard and wrote: On Mon, Sep 02, 2013 at 08:06:17AM -0700, David Guntner wrote: Matej Kosik grabbed a keyboard and wrote: Hello, This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? What do you mean by appears in a subshell? From man 1 bash: (list) list is executed in a subshell environment (see COMMAND EXECU‐ TION ENVIRONMENT below). Variable assignments and builtin com‐ mands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list. Ok, I'm still not following you. What, exactly, is it that you are doing at your keyboard, in order to run it in this subshell? I'm assuming that in your main one you're just typing the expression and hitting enter. So what are you doing when the second example fails? --Dave smime.p7s Description: S/MIME Cryptographic Signature
Re: strange bash behavior
On Mon, 02 Sep 2013 05:27:55 -0400 (EDT), Matej Kosik wrote: This morning I have been puzzled by bash. After typing the following command: for i in `seq 1 5`;do echo $i; test $i = 3 break; done I see: 1 2 3 Which is OK. However, if the break command appears in a subshell: for i in `seq 1 5`;do echo $i; test $i = 3 (break); done then the break command does not seem to have any effect 1 2 3 4 5 I am curious, is this something to be expected? Interesting. If break appears out of context, you should get an error message something like: bash: break: only meaningful in a 'for', 'while', or 'until' loop You didn't get an error message, so part of bash thinks it is in context. Yet it did not exit the loop. It seems to me that you should get one behavior or the other. Either you should get an error message or it should exit the loop. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1155847423.2945873.1378139177503.javamail.r...@md01.wow.synacor.com
