Re: Odd bash behaviour with time:
Ángel González an...@16bits.net writes: time | foo ksh fails the same as bash: ksh: syntax error at line 1: `|' unexpected Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different.
Re: Odd bash behaviour with time:
On Tue, Nov 4, 2014 at 1:24 AM, Ángel González an...@16bits.net wrote: Piotr Grzybowski wrote: Hi Chet, hi all. [..] There are more syntax errors equivalent to the time; case: time time bar time | foo time || true thanks for pointing that out. Some of these require more attention I think. Lets see if my poor knowledge of bash parser is enough to fix them :) cheers, pg
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 11/3/14 5:08 PM, Graham Jones wrote: These are for: bash --version GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0) This trace looks pretty reasonable. Maybe you could temporarily move your history file to some other name and see if you can reproduce this behavior starting fresh with an empty history file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Multiline prompt problems with long commands
On 11/3/14 6:50 PM, Kamil Neczaj wrote: Bash Version: 4.3 Patch Level: 30 Release Status: release Description: When using multiline prompt and entering a long command, the part which doesn't fit and should be moved to a new line is actually move to the beginning of the same line which makes the command unreadable. Repeat-By: 1. Set e.g. PS1=\n\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[01;33m\]\n\n\033[01;31m\]- \[\e[0m\] ^^^ ||| Before I look at this, why is this sequence not marked as invisible? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Multiline prompt problems with long commands
Hey Kamil, as Chet pointed out, you missed one '\[', this one works: PS1=\n\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[01;33m\]\n\n\[\033[01;31m\]- \[\e[0m\] cheers, pg
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Hi, reproducible on mac os x 10.6.8 # uname -a Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 # bash --version GNU bash, version 4.3.24(1)-release (x86_64-apple-darwin10.8.0) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Graham: could you please send the output of these commands: # cat .bash_history | wc -l # echo $HISTFILESIZE # echo $HISTSIZE it obviously happens when you are almost at the level of $HISTFILESIZE with `cat .bash_history | wc -l`. cheers, pg On Tue, Nov 4, 2014 at 2:54 PM, Chet Ramey chet.ra...@case.edu wrote: On 11/3/14 5:08 PM, Graham Jones wrote: These are for: bash --version GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0) This trace looks pretty reasonable. Maybe you could temporarily move your history file to some other name and see if you can reproduce this behavior starting fresh with an empty history file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] bracketed paste support
Daniel Colascione wrote: Bob Proulx wrote: I use paste into the shell with an embedded newline in order to immediately execute a command *a lot*. If that were removed I would be very unhappy. I strongly doubt that your use case is typical. It doesn't matter if it is typical or not. A feature need not have a 51% majority in order to be retained. Everyone does things differently. If we were to examine your operating modes carefully I am sure that we would find some practice that you use often that few other people are using and would be annoyed greatly if removed. Furthermore it is impossible to know how many people use it. This is a long standing feature that if removed would disenfranchise the users of it. That is all that we can say about it. I very often triple-click to select by line and then paste it into the shell for immediate execution. I less often triple-click to select multiple lines of a command set and paste them into the shell for immediate execution. I am sure there are many others not in this discussion who do the same. I've asked several of my colleagues; all have complained about accidentally pasting a large amount of text into the shell at one time or another. Nobody has complained about losing automatic execution of code after paste. Unfortunately that is not a useful survey. It is self-fullfilling! If I ask ten of my peers of whom I have each taught a feature if they use that feature then the answer will of course be yes. If on the other hand I have vilified a feature with my peers then it is likely that the reverse would be true. A survey asking colleagues around you is simply not a worthwhile survey. Sorry. Knowledge and use tends to group and cluster. Birds of a feather flock together. This is one of the reasons why things like conferences, newsgroups, and mailing lists are so useful. It allows people to meet others and learn about practices outside of their normal routine. People not only learn other things for themselves but they also learn that there is diversity in others too. In this case you learn that a feature that you despise is one that is liked by another. Speaking from personal experience, I've been using terminal emulators of various sorts for almost 20 years, and in that time, I've accidentally pasted documents into my terminal orders of magnitude more often than I've deliberately pasted multi-command sequences. I have used terminals for a very long time as well. I am using one now. I won't say that I haven't sometimes pasted in paragraphs of text into a terminal by mistake. I have. I also use kitchen knives to chop vegetables. I have sometimes cut myself doing so. That doesn't prevent me from avoiding cutting up vegetables with a kitchen knife. I have also accidentally removed a file with rm that I didn't intend to remove. In none of those cases do I want to remove rm or kitchen knives from the world to prevent anyone from doing either of those things again. As far as I'm concerned, automatic execution of code on paste isn't a feature: it's a bug and security hole. Users should have to opt into security holes. It is not a security hole. Simply declaring it to be so does not make it so. I get that it is a feature you hate. But labeling it with incorrect negative labels is simply a normal day of US political advertisements. It has no business on a technical list. We've only lived with the existing behavior so long because it's only recently become possible to distinguish pastes from other input. And I think it is great that you can now have it operate differently. Isn't it a wonderful world that we live in? Bob
Re: Multiline prompt problems with long commands
Hello, Thank you for your response! I modified this prompt couple of times, probably that's why it's like this. Anyway, I don't think this should cause the problem. The PS1 variable is the one I use. I wanted to copy it here to have exactly the example which I know that causes problems for sure. Regards, Kamil Neczaj 2014-11-04 15:06 GMT+01:00 Chet Ramey chet.ra...@case.edu: On 11/3/14 6:50 PM, Kamil Neczaj wrote: Bash Version: 4.3 Patch Level: 30 Release Status: release Description: When using multiline prompt and entering a long command, the part which doesn't fit and should be moved to a new line is actually move to the beginning of the same line which makes the command unreadable. Repeat-By: 1. Set e.g. PS1=\n\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[01;33m\]\n\n\033[01;31m\]- \[\e[0m\] ^^^ ||| Before I look at this, why is this sequence not marked as invisible? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: Multiline prompt problems with long commands
Kamil Neczaj writes: Thank you for your response! I modified this prompt couple of times, probably that's why it's like this. Anyway, I don't think this should cause the problem. The PS1 variable is the one I use. I wanted to copy it here to have exactly the example which I know that causes problems for sure. Why don't you think this could cause the problem? You're missing the zero width leader/terminator for that section, bash doesn't know how long your prompt is (and thus when to wrap) without it. Did you actually *try* the suggested fix before you replied? pgpjCOfEmHOKB.pgp Description: PGP signature
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 5 Nov 2014, at 4:49 am, Piotr Grzybowski narsil...@gmail.com wrote: Hi, reproducible on mac os x 10.6.8 Really? Very interesting. I assume that it’s not reproducible with the version of bash that ships with 10.6.8 however? This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Graham: could you please send the output of these commands: # cat .bash_history | wc -l # echo $HISTFILESIZE # echo $HISTSIZE it obviously happens when you are almost at the level of $HISTFILESIZE with `cat .bash_history | wc -l`. Not at all. I keep my history for a long time and have an arbitrarily large HISTSIZE. However, after the recent Yosemite upgrade, histories were truncated, so it’s relatively empty and nowhere near the level of HISTFILESIZE after the 20 or so returns that I enter reproduce it (and I’m not sure that just hitting enter even puts anything in the history). Here are the details you wanted: graham@zebedee:~$ set | grep HIST HISTFILE=/Users/graham/.bash_history HISTFILESIZE=50 HISTSIZE=50 graham@zebedee:~$ wc -l $HISTFILE 21 /Users/graham/.bash_history cheers, pg On Tue, Nov 4, 2014 at 2:54 PM, Chet Ramey chet.ra...@case.edu wrote: On 11/3/14 5:08 PM, Graham Jones wrote: These are for: bash --version GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0) This trace looks pretty reasonable. Maybe you could temporarily move your history file to some other name and see if you can reproduce this behavior starting fresh with an empty history file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Hi Graham, On Tue, Nov 4, 2014 at 10:19 PM, Graham Jones your-name-h...@grahamjones.org wrote: Really? Very interesting. I assume that it’s not reproducible with the version of bash that ships with 10.6.8 however? not exactly the version shipped with 10.6.8, more like installed by hand: # which bash /opt/local/bin//bash Not at all. I keep my history for a long time and have an arbitrarily large HISTSIZE. However, after the recent Yosemite upgrade, histories were truncated, so it’s relatively empty and nowhere near the level of HISTFILESIZE after the 20 or so returns that I enter reproduce it (and I’m not sure that just hitting enter even puts anything in the history). well, thats strange, but it means that this also should do the trick, without setting PROMPT_COMMAND: # i=0; while [ $i -lt 25 ]; do history -a; history -n; let i++; done; it actually does for me, anything above 24 in the upper limit of the above loop triggers the issue (no PROMPT_COMMAND set anywhere). at the same time, the same loop does nothing out of the ordinary on linux/i386 with bash--version: #bash --version GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu) Here are the details you wanted: [..] thanks, nice HISTSIZE btw ;-) cheers, pg
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On 5 Nov 2014, at 12:54 am, Chet Ramey chet.ra...@case.edu wrote: On 11/3/14 5:08 PM, Graham Jones wrote: These are for: bash --version GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0) This trace looks pretty reasonable. Maybe you could temporarily move your history file to some other name and see if you can reproduce this behavior starting fresh with an empty history file. As you may have seen from the other email, the history file is relatively small. I did just remove it and start afresh, and the issue still occurs. Whilst attempting to reproduce it, I noticed that is doesn’t reoccur immediately. In my first test, I deleted the history file and closing that session (the only one). When I created a single terminal session, I could su to root and hit return a large number of times without it reproducing the error. I need created another terminal session and (without suing) after issue just a single command, the next command on the root terminal exhibited the behaviour. I retried a similar experiment, again after removing the history file, and again it wasn’t immediately reproducible. This time I didn’t create a second session but left the terminal along for 3 or 4 minutes. When I next entered a command the behaviour has returned. In both cases the line count in $HISTFILE was low = ~40. Now after performing these to experiments I just tried to create a new session and found my $HISTFILE owned by root (or at least permission denied, I didn’t actually check the file mode and owner before chmoding it). This seems strange given I never log in as root only su so presumably the first command executed must always be by my own user. After chmoding it, I notice this: graham@zebedee:~$ wc -l $HISTFILE 51 /Users/graham/.bash_history I have obviously not entered that many commands! Immediately after I go to check the contents and it’s owned by root again graham@zebedee:~$ wc -l $HISTFILE wc: /Users/graham/.bash_history: open: Permission denied graham@zebedee:~$ l $HISTFILE -rw--- 1 root staff 150 4 Nov 21:36 /Users/graham/.bash_history graham@zebedee:~$ ps aux |grep bash graham 99600 0.0 0.0 2432772648 s000 S+9:40pm 0:00.00 grep bash graham 99555 0.0 0.5 2492596 39076 s000 S 9:36pm 0:00.49 -bash But yet there is only my bash running non-priveledge. Now I was expecting a hole in the file, but when I finally get to see the contents, I have 500,000 ls commands in there (one of my test commands from above) graham@zebedee:~$ wc -l $HISTFILE wc: /Users/graham/.bash_history: open: Permission denied graham@zebedee:~$ sudo chown graham $HISTFILE Password: graham@zebedee:~$ sort $HISTFILE | uniq -c | sort -n 1 sudo chown graham $HISTFILE 1 vi $HISTFILE 50 ls Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
On Tue, Nov 4, 2014 at 10:44 PM, Graham Jones your-name-h...@grahamjones.org wrote: Now I was expecting a hole in the file, but when I finally get to see the contents, I have 500,000 ls commands in there (one of my test commands from above) just for the record, now I have $HISTSIZE i=0; while [ $i -lt 25 ]; do history -a; history -n; let i++; done; commands in .bash_history :) cheers, pg P.S. pity I really needed those ;-)
Re: PROMPT_COMMAND='history -a; history -n' causes shell hang in OX 10.10 Yosemite / bash 3.2.53
Chet: for reasons unexplained calls to read_history_range at history.def:219 219 result = read_history_range (filename, history_lines_in_file, -1); return more and more records (77824 is above my HISTFILESIZE): 1: history_lines_in_file = 77824 the loop at histfile.c:269 in read_history_range is the one that hangs. code at commit ca6a2ba40c709c2b45a56e49d21d0dfc66e21974 Date: Sun Oct 5 19:12:20 2014 -0400 cheers, pg On Tue, Nov 4, 2014 at 2:54 PM, Chet Ramey chet.ra...@case.edu wrote: On 11/3/14 5:08 PM, Graham Jones wrote: These are for: bash --version GNU bash, version 4.3.30(1)-release (x86_64-apple-darwin14.0.0) This trace looks pretty reasonable. Maybe you could temporarily move your history file to some other name and see if you can reproduce this behavior starting fresh with an empty history file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
