Re: Commandline history recall not working properly
> I am facing a problem on the console with bash. Bash simply does > not remember my commands in the right order. Most of the commands I > type in a login session are forgotten in the next session. Moving the > Up and Down arrow keys navigates a highly incorrect and incomplete > command history. Even doing a Ctrl-R for reverse search almost never > finds any command I entered in any previous session. It may be that you're saving the contents of multiple sessions to the same history file, whose size is limited to 1000 entries. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: bash handles bytes instead of chars
®om wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i486 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' > -DCONF_OSTYPE='lin$ > uname output: Linux rom-laptop 2.6.24-21-generic #1 SMP Mon Aug 25 > 17:32:09 UTC$ > Machine Type: i486-pc-linux-gnu > > Bash Version: 3.2 > Patch Level: 39 > Release Status: release The Posix standard is pretty explicit that printf(1), because of the underlying formatted output functions it uses, is byte-oriented. There is support for wide characters, but not for multibyte ones. For instance, strings printed with %s are bytes, precisions determine the number of bytes printed, and return values are numbers of bytes. I will take a look at the standard and see what it says about bytes in the format string. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Graceful Exit
Hello, I am writing a System Report script for Ubuntu, and even 'though I have the word exit on the last line of the script, when I run the script in terminal I have to hit enter a second time after running the script to get the terminal prompt back. I'm uploading the script, have a look and tell me how to get this thing to exit back to the terminal prompt without the second enter key press. Thanks, Ray Parrish http://www.nabble.com/file/p19598628/SystemReport.sh SystemReport.sh -- View this message in context: http://www.nabble.com/Graceful-Exit-tp19598628p19598628.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: bash handles bytes instead of chars
Chet Ramey a écrit :
®om wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='lin$
uname output: Linux rom-laptop 2.6.24-21-generic #1 SMP Mon Aug 25
17:32:09 UTC$
Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
The Posix standard is pretty explicit that printf(1), because of the
underlying formatted output functions it uses, is byte-oriented. There
is support for wide characters, but not for multibyte ones. For instance,
strings printed with %s are bytes, precisions determine the number of
bytes printed, and return values are numbers of bytes.
I will take a look at the standard and see what it says about bytes in
the format string.
Chet
printf was only a way to send 0xe282ac on stdin of each tool, it doesn't
matter how printf interprets the bytes. What is important is how the
tool ("cut" for example, or read -n) interprets them :)
Re: bash handles bytes instead of chars
®om wrote:
> printf was only a way to send 0xe282ac on stdin of each tool, it doesn't
> matter how printf interprets the bytes. What is important is how the
> tool ("cut" for example, or read -n) interprets them :)
I don't have any control over the various implementations of `cut' out
there. The `read -n' issue already generated debate, and I decided to
change it to act on multibyte characters in the next version of bash.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Bash RFE: Goto (especially for jumping while debugging)
Dear All, Here's a rather controversial request, namely that bash should support 'goto'. The reason I'd like to see it is to make debugging long scripts easier. I'm working at the moment on a 2000+ line script, and if I want to test stuff at the end, I'd really like to have something like the following: --- #!/bin/bash #initialisation stuff goes here. goto LABEL #lots of stuff here that I want to skip. #Bash doesn't have a multi-line comment feature. #Even if it did, one can't do a multi-line comment containing #another multi-line comment. A good editor makes this less #painful, but isn't an ideal solution. LABEL #stuff I want to test exit #stuff at the end of the script, which I don't want to run while testing. -- We already have exit, which is really short for "jump directly to the end". What would be great is a way to "jump into the middle". What do you think? Richard P.S. I am sure lots of people will complain (correctly) that "Goto is considered harmful". I'd agree that, in most cases, it is. But in some cases, such as the above, it's quite useful. Maybe the feature could be called "debug-goto" in order to emphasise its debugging nature, as opposed to use in a regular program. P.P.S. a hack that would demonstrate what I mean could be implemented by abusing heredocs. Instead of goto LABEL .. LABEL write cat >/dev/null <<'label_foo' ... LABEL This has exactly the same effect.
Re: Bash RFE: Goto (especially for jumping while debugging)
On Mon, 2008-09-22 at 20:44 +0100, Richard Neill wrote: > How about... > --- > #!/bin/bash > > #initialisation stuff goes here. > if false; then > > #lots of stuff here that I want to skip. > #Bash doesn't have a multi-line comment feature. > #Even if it did, one can't do a multi-line comment containing > #another multi-line comment. A good editor makes this less > #painful, but isn't an ideal solution. > fi > > #stuff I want to test > > exit > > #stuff at the end of the script, which I don't want to run while testing. > -- b. signature.asc Description: This is a digitally signed message part
Re: ctrl-C and command lists
Julian Bradfield wrote: > In every other shell I've used, the behaviour of ctrl-C in an > interactive shell is to interrupt the current command-line and return > to the shell prompt. > This is, I think, the behaviour expected by the user in almost all > circumstances. In the rare circumstance when one doesn't want to do > that, traps can be used. > > Historically, bash has taken the approach that ctrl-C interrupts the > currently executing pipeline, but that's all. That results in the mad > panic when one does: > > for f in * ; do destroy $f ; sleep 1; done > oh-shit-ctrl-C-ctrl-C-ctrl-C-oh-shit-ctrl-Z-I-hate-bash! > > I see that the most recent bash has now changed its behaviour so > that ctrl-c breaks out of any executing loops, thereby solving the > above problem. > > However, as pointed out recently by "jidanni" in RISKS 25.31, bash > still executes the rest of a list: > > sleep 36 ; launch_shuttle > oops, found a problem with the O-rings, ctrl-C > VROOM! > > > I argue that bash should do what the user expects: in the absence of > traps, SIGINT should return to the prompt. I will make this change for the next version. Keep in mind that it's a problem because of the way job control works -- unless other arrangements are made, bash doesn't get the SIGINT sent to the foreground process group. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Bash RFE: Goto (especially for jumping while debugging)
Richard Neill wrote: > Dear All, In the future please start a new message for a new thread of discussion. When you reply to old messages from three months ago those of us who actually keep months worth of email see the message threaded with the previous discussion about variables and subshells. If anyone has killed that thread then the continuation is also killed. > Here's a rather controversial request, namely that bash should support > 'goto'. Although goto does have uses it is definitely a keyword of the damned. > cat >/dev/null <<'label_foo' ... LABEL > This has exactly the same effect. I actually was going to reply and suggest exactly the above. But then realized you had already suggested it. Normally I would do a commented out section. Easy and non-controversial. Or I would do if false; then...fi For just a comment section this doesn't seem to be a compelling need. For that you would need to show how writing state-machines or something is so much easier or some such... Since there are other possibilities I would vote to maintain the status quo. Bob
Re: Bash RFE: Goto (especially for jumping while debugging)
Bob Proulx wrote: Richard Neill wrote: Dear All, In the future please start a new message for a new thread of discussion. When you reply to old messages from three months ago those of us who actually keep months worth of email see the message threaded with the previous discussion about variables and subshells. If anyone has killed that thread then the continuation is also killed. D'oh! Sorry about that. I had always thought that editing the subject line was what changed the thread, rather than some internal state variable in the mail-client. I stand corrected. BTW, doesn't bash have a bugzilla? Here's a rather controversial request, namely that bash should support 'goto'. Although goto does have uses it is definitely a keyword of the damned. cat >/dev/null <<'label_foo' ... LABEL This has exactly the same effect. I actually was going to reply and suggest exactly the above. But then realized you had already suggested it. That does work. Actually, maybe the way is to define a function called "goto", which handles the common case of a forward jump. Normally I would do a commented out section. Easy and non-controversial. Or I would do if false; then...fi No good if one wants to jump over/out-of a control structure. For just a comment section this doesn't seem to be a compelling need. For that you would need to show how writing state-machines or something is so much easier or some such... I think existing functionality would work. Given that 'goto' would intentionally over-ride all other control structures, then I can suggest 2 ways this might be implemented: i. Treat goto as "exit", but don't clean up variables and functions. Then, go back to the start, skipping all instructions till LABEL. Doing it this way means that goto quits out of all nested control structures. ii. Source $0, but skip all instructions till LABEL. Doing it this way means that goto does not quit out of any nested control structures. Best wishes, Richard
Re: Bash RFE: Goto (especially for jumping while debugging)
Richard Neill wrote: > Bob Proulx wrote: > >In the future please start a new message for a new thread of > >discussion. When you reply to old messages from three months ago > >those of us who actually keep months worth of email see the message > >threaded with the previous discussion about variables and subshells. > >If anyone has killed that thread then the continuation is also killed. > > D'oh! Sorry about that. I had always thought that editing the subject > line was what changed the thread, rather than some internal state > variable in the mail-client. I stand corrected. Mail uses In-Reply-To: and References: headers. By the time you have deleted all of them it is easier to start a new message. > BTW, doesn't bash have a bugzilla? GNU projects tend to use Savannah. But this isn't universial. https://savannah.gnu.org/projects/bash Bob
Darwin-Bug
Configuration Informatio= n [Automatically generated, do not change]: Machine: powerpc OS: darwin9.0 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' - DCONF_OSTYPE='\ darwin9.0' -DCONF_MACHTYPE='powerpc-apple-darwin9.0' -DCONF_VENDOR= 'apple' -DLO\ CALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_= H -DMACOSX \ -I. -I/SourceCache/bash/bash-76.1/bash -I/SourceCache/bash/bash-76. 1/bash/inc\ lude -I/SourceCache/bash/bash-76.1/bash/lib -I/SourceCache/bash/bash-76 .1/bash/\ lib/intl -I/var/tmp/bash/bash-76.1~4/lib/intl -arch i386 -arch ppc -= g -Os -pip\ e -no-cpp-precomp -mdynamic-no-pic -DM_UNIX -arch i386 -arch ppc -pipe<= br> uname output: Darwin Macintosh.local 9.2.0 Darwin Kernel Version 9.2.0:= Tue Feb\ 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386 i386 Machine Type: powerpc-apple-darwin9.0 Bash Version: 3.2 Patch Level: 17 Release Status: release -11-:---F1 bbug1 Top L1 (Fundamental) - Nader "StandingTurkey" Hedayat-Vaziri _ Visit the Cherokee Nation at http://www.cherokee.o= rg Get your own emal service at [1]ZZN.COM. References 1. file://localhost/tmp/3D'htt
