How can i specify the scripting language used for parsing a script?
#!/bin/sh echo ppp echo $SHELL exit 2200 In the above script i tried to specify /bin/sh as my parser by a comment. Is that OK? When I type ./scr2 , i want bash recognize /bin/sh as the parser of ./scr2.
Re: Why sh does not return a false value?
On Sat, 5 Feb 2011 16:17:05 +0330 ali hagigat hagigat...@gmail.com wrote: if (sh -c exit 34) then echo p;fi p The following condition should be false, because our exit value is non-zero. but 'if' considers the condition as true and executes 'echo' command. Why? Try if (sh -c 'exit 34') then echo ; fi and read about the -c option in the man page. -- D.
Re: Why sh does not return a false value?
On 05 Feb 2011, at 13:47, ali hagigat wrote: if (sh -c exit 34) then echo p;fi p The following condition should be false, because our exit value is non-zero. but 'if' considers the condition as true and executes 'echo' command. Why? You are giving -c the argument 'exit' and setting 34 as the zero'th argument to the script. It's vital to understand what word splitting is. Quotes are used to keep words together so they are passed as a single argument. -c takes only one single argument, so to pass the command exit 34 to -c, you quote it.
Proposed enhancement to bind builtin
As far as I know, there is currently no way to display shell-command key bindings. I would like to propose that bind -x and bind -X without additional arguments perform this function in a manner parallel to -[sSvVpP].
No Color for Bash Completion Results
When using bash completion on files within local folder, ie. $ ls ftab showing results for files starting with char f -- or any char(s) you may specify, results are not provided in color when bash, terminal and ls are configured for using color. I do believe, results for bash completion on files were at one time in color. To further troubleshoot, I removed /etc/bash/bashrc and $HOME/.bashrc and only enabling related color commands. I have tracked this down to the call: compgen -d -- $quoted (Give or take some commands as I found this by using strace/ltrace or grepping the files belonging to bash/bash-completion packages.) Doing something like compgen -d |ls --color does provide color, but is likely not proper. I believe compgen is provided by bash and not bash-completion. Using the following packages: =app-shells/bash-4.1_p9 =app-shells/bash-completion-1.2 =app-shells/gentoo-bashcomp-20101217 Using both rxvt-unicode and framebuffer console. Grepping around, I can see no references to anything color related when dealing with compgen or $COMPREPLY. I did trace the ls (core-utils) to /usr/share/bash-completion/base of bash-completion. Any ideas? -- Roger http://rogerx.freeshell.org/
Re: How can i specify the scripting language used for parsing a script?
On 05 Feb 2011, at 17:09, Andreas Schwab wrote: Maarten Billemont lhun...@gmail.com writes: The comment is called a hashbang or shebang. It tells the kernel which program to start. Your script is passed over stdin to the interpreter. No, it isn't, it's passed as the argument. Andreas. Of course, otherwise ./myscript file wouldn't work.
Re: No Color for Bash Completion Results
On Sat, Feb 5, 2011 at 1:35 PM, Roger rogerx@gmail.com wrote: When using bash completion on files within local folder, ie. $ ls ftab showing results for files starting with char f -- or any char(s) you may specify, results are not provided in color when bash, terminal and ls are configured for using color. I do believe, results for bash completion on files were at one time in color. To further troubleshoot, I removed /etc/bash/bashrc and $HOME/.bashrc and only enabling related color commands. I have tracked this down to the call: compgen -d -- $quoted (Give or take some commands as I found this by using strace/ltrace or grepping the files belonging to bash/bash-completion packages.) Doing something like compgen -d |ls --color does provide color, but is likely not proper. I believe compgen is provided by bash and not bash-completion. Using the following packages: =app-shells/bash-4.1_p9 =app-shells/bash-completion-1.2 =app-shells/gentoo-bashcomp-20101217 Using both rxvt-unicode and framebuffer console. Grepping around, I can see no references to anything color related when dealing with compgen or $COMPREPLY. I did trace the ls (core-utils) to /usr/share/bash-completion/base of bash-completion. Any ideas? -- Roger http://rogerx.freeshell.org/ Zsh does that and fish does match highlighting in color. I don't remember ever seeing Bash do it, though.
Re: No Color for Bash Completion Results
On Sat, Feb 05, 2011 at 01:58:39PM -0600, Dennis Williamson wrote: On Sat, Feb 5, 2011 at 1:35 PM, Roger rogerx@gmail.com wrote: When using bash completion on files within local folder, ie. $ ls ftab showing results for files starting with char f -- or any char(s) you may specify, results are not provided in color when bash, terminal and ls are configured for using color. I do believe, results for bash completion on files were at one time in color. Zsh does that and fish does match highlighting in color. I don't remember ever seeing Bash do it, though. OK. Maybe not then. But thinking on it, maybe I was using an incantation of ZSH at one time using $ or # for the prompt. Or, maybe the command completion files was hacked to pipe to 'ls --color'. shrugs -- Roger http://rogerx.freeshell.org/
Re: Bash-4.2-rc2 available for FTP
On 2/5/11 1:03 PM, Mike Frysinger wrote: On Wednesday, February 02, 2011 21:49:38 Chet Ramey wrote: On 2/2/11 6:27 PM, Mike Frysinger wrote: - lib/glob/smatch.c needs externs.h for mbsmbchar. seems like externs.h could do with including bashtypes.h/command.h/general.h too since it needs basic types from all of those. Or an extern declaration for mbsmbchar, to avoid having to include other files. that defeats the whole point of having a single extern line. Yes, I understand the tradeoff. -- ``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: multi-line commands in the history get split when bash is quit
Slevin McGuigan wrote: I am unsure whether or not this a bug. Anyhow, it is pretty annoying... I use simple multi-line scripts very often in bash and use vi mode to edit them. By using # shopt -s cmdhist # shopt -s lithist I can achive multi-line editing. Which is fine. But this ability breaks as soon as I close bash and open it again. Is this a bug? Are there suggestions for workarounds? Are you thinking that setting shopts should in some way be persistent across program invocations? That would be pretty annoying and a severe bug if it did. Are you forgetting to put your desired configuration into ~/.bashrc where it is loaded when bash starts? Are you forgetting to put source $HOME/.bashrc into your ~/.bash_profile where it will source your .bashrc when you log into your account? Bob
Re: multi-line commands in the history get split when bash is quit
On Sat, Feb 5, 2011 at 17:51, Bob Proulx b...@proulx.com wrote: Are you thinking that setting shopts should in some way be persistent across program invocations? That would be pretty annoying and a severe bug if it did. Are you forgetting to put your desired configuration into ~/.bashrc where it is loaded when bash starts? Are you forgetting to put source $HOME/.bashrc into your ~/.bash_profile where it will source your .bashrc when you log into your account? No. Read his email again.
Re: multi-line commands in the history get split when bash is quit
On Sat, Feb 5, 2011 at 15:56, Slevin McGuigan slevin.mcgui...@googlemail.com wrote: I am unsure whether or not this a bug. From what I can tell, it's not so much a bug as it is an inadequacy: When you quit bash, the history is stored very naively in $HISTFILE; the history is simply dumped to it line-by-line, and each line of the file is later interpreted by a new bash instance as a complete command line input. Hence, the multi-line nature of your command input is lost between dumping it to $HISTFILE and later populating the history from $HISTFILE. The solution would be to invent a more robust file format for $HISTFILE.
Re: multi-line commands in the history get split when bash is quit
On Sat, 5 Feb 2011, Michael Witten wrote: On Sat, Feb 5, 2011 at 18:02, Jon Seymour jon.seym...@gmail.com wrote: The version I tried on Linux 3.2.25 does have a .bash_history format that could support it, but it still behaved the same way. How do you mean? I'm running bash version 4.1.9(2)-release on GNU/Linux, and the resulting history file doesn't seem like it's storing anything more than lines of text naively dumped from the multi-line example. According to the man page, HISTTIMEFORMAT ... If this variable is set, time stamps are written to the history file so they may be preserved across shell sessions. However this is not done in any version of bash that I can find. -- Chris F.A. Johnson, http://cfajohnson.com/ Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: multi-line commands in the history get split when bash is quit
Here's the format I see in my history. #1296950184 for i in 1 2 do echo $i done #1296950194 exit HISTTIMEFORMAT is: HISTTIMEFORMAT='[%m.%d.%y] %T ' bash -version is: GNU bash, version 3.2.25(1)-release (i686-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. jon. On Sun, Feb 6, 2011 at 11:51 AM, Jon Seymour jon.seym...@gmail.com wrote: In the version I was using a line that began with # and perhaps a timestamp separated each entry of the history in a way that in principle preserved information about the entry boundary even though this information is not used by bash on the subsequent start. jon. On 06/02/2011, at 11:24, Michael Witten mfwit...@gmail.com wrote: On Sat, Feb 5, 2011 at 18:02, Jon Seymour jon.seym...@gmail.com wrote: The version I tried on Linux 3.2.25 does have a .bash_history format that could support it, but it still behaved the same way. How do you mean? I'm running bash version 4.1.9(2)-release on GNU/Linux, and the resulting history file doesn't seem like it's storing anything more than lines of text naively dumped from the multi-line example.
Re: multi-line commands in the history get split when bash is quit
On Sun, Feb 6, 2011 at 1:07 PM, Michael Witten mfwit...@gmail.com wrote: On Sat, Feb 5, 2011 at 20:02, Michael Witten mfwit...@gmail.com wrote: So, if you run `history', you'll not only get the commands in the history list, but you'll also get the time at which the commands were last run (formatted according to $HISTTIMEFORMAT). In other words, it's not helpeful in this case. Of course, I suppose bash could be taught to build multi-line comments from command lines that share the same timestamp, but given the nature of how that information is recorded, it seems like it may not be a very robust solution. You don't have to do that - the timestamp is encoded in a comment line between entries. See the example below. One could simply assume all lines between two lines beginning with # are part of the one entry, #1296950290 pwd #1296950293 bash -version #1296950327 for i in 1 2 do echo $i done #1296950337 jon.
Re: multi-line commands in the history get split when bash is quit
On Sat, Feb 5, 2011 at 20:12, Jon Seymour jon.seym...@gmail.com wrote: You don't have to do that - the timestamp is encoded in a comment line between entries. See the example below. One could simply assume all lines between two lines beginning with # are part of the one entry, That's what I was saying. However, it seems like an unrobust way have handling the situation (both for multi-line comments and for the existing timestamp purposes).
Re: multi-line commands in the history get split when bash is quit
On Sat, Feb 5, 2011 at 20:09, Jon Seymour jon.seym...@gmail.com wrote: I guess the point is that in versions of bash that do store the timestamp in the .bash_history file To clarify, the timestamp is stored whenever HISTTIMEFORMAT has a non-null value; the bash version doesn't particularly matter unless you're suggesting that HISTTIMEFORMAT is non-null by default under some bash versions. If there aren't really any concerns about using the same history file with older versions of bash, then wouldn't it be better to have a new file format that can handle multi-line commands more directly?
