Re: wrong lineno inside trap?
peter360 wrote: > I wrote a test program test.sh: > > trap ' > > echo this is line 3, but LINENO=$LINENO > > ' 0 > > echo this is line 7, and LINENO=$LINENO > --- > when I ran it I got > $ sh /tmp/test.sh > this is line 7, and LINENO=7 > this is line 3, but LINENO=11 > > My bash version is > $ sh --version > GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) > Copyright (C) 2005 Free Software Foundation, Inc. > > Is this a known problem? Thanks. Bash-4.0 should behave better in this area, but quoted strings will always cause unpredictable values for $LINENO. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Quick question: mv !(file) !$
Yang Zhang wrote:
> Hi, why doesn't the second command work? (Trying to move all files into
> a newly created directory.)
>
> $ mkdir dhclient
> $ mv !(dhclient) !$
> bash: !: event not found
It doesn't work because enabling the `extglob' option doesn't cause bash
to tell the history library to not attempt history expansion when it sees
the history expansion character followed by a `('. This will be fixed in
bash-4.0 or soon after.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Bash-4.0-rc1 available for FTP
The first public release candidate of bash-4.0 is now available with the URL
ftp://ftp.cwru.edu/pub/bash/bash-4.0-rc1.tar.gz
This tar file does not include the formatted documentation (you
should be able to generate it yourself).
This release fixes the remaining serious bugs in the bash version 3 branch
and introduces significant new features.
The most notable new features are associative arrays, improvements to the
programmable completion functionality, case-modifying word expansions,
co-processes, support for the `**' special glob pattern, and additions to
the shell syntax and redirections. The shell has been changed to be more
rigorous about parsing commands inside command substitutions, fixing one
piece of Posix non-compliance.
`bashbug' may be used to report bugs with this version.
As always, thanks for your help.
Chet
+== CHANGES ==+
This document details the changes between this version, bash-4.0-rc1,
and the previous version, bash-4.0-beta2.
1. Changes to Bash
a. Fixed a bug that caused parsing errors when a $()-style command
substitution was follwed immediately by a quoted newline.
b. Fixed a bug that caused extended shell globbing patterns beginning with
`*(' to not work when used with pattern substitution word expansions.
--
This document details the changes between this version, bash-4.0-beta2,
and the previous version, bash-4.0-beta.
1. Changes to Bash
a. Fixed a bug that caused failed word expansions to set $? but not
PIPESTATUS.
b. Changed filename completion to quote the tilde in a filename with a
leading tilde that exists in the current directory.
c. Fixed a bug that caused a file descriptor leak when performing
redirections attached to a compound command.
d. Fixed a bug that caused expansions of $@ and $* to not exit the shell if
the -u option was enabled and there were no posititional parameters.
e. Fixed a bug that resulted in bash not terminating immediately if a
terminating signal was received while performing output.
f. Fixed a bug that caused the shell to crash after creating 256 process
substitutions during word completion.
2. Changes to Readline
a. Fixed a bug that caused redisplay errors when using prompts with invisible
characters and numeric arguments to a command in a multibyte locale.
b. Fixed a bug that caused redisplay errors when using prompts with invisible
characters spanning more than two physical screen lines.
--
This document details the changes between this version, bash-4.0-beta,
and the previous version, bash-4.0-alpha.
1. Changes to Bash
a. Fixed a typo that caused a variable to be used before initialization
while parsing Posix-style command substitutions.
b. Fixed a bug that caused stray ^? when the expansion of a parameter used
as part of a pattern removal expansion is empty, but part of a non-
empty string.
c. Fixed a bug that could cause strings not converted to numbers by strtol
to be treated as if the conversion had been successful.
d. The `return' builtin now accepts no options and requires a `--' before
a negative return value, as Posix requires.
e. Fixed a bug that caused local variables to be created with the empty
string for a value rather than no value.
f. Changed behavior so the shell now acts as if it received an interrupt
when a pipeline is killed by SIGINT while executing a list.
g. Fixed a bug that caused `declare var' and `typeset var' to initialize
`var' to the empty string.
h. Changed `bind' builtin to print a warning but proceed if invoked when
line editing is not active.
i. Fixed a bug that caused the shell to exit when the `errexit' option is
set and a command in a pipeline returns a non-zero exit status.
j. Fixed a bug that caused the shell to not run the exit trap in a command
run with `bash -c' under some circumstances.
k. Fixed a bug that caused parser errors to occasionally not set $? when
running commands with `eval'.
l. Fixed a bug that caused stray control characters when evaluating compound
array assignments containing $'\x7f' escapes.
m. Fixed a bug that caused redirections involving file descriptor 10 as the
target to behave incorrectly.
n. Fixed a bug that could cause memory to be freed multiple times when
assigning to COMP_WORDBREAKS.
o. Fixed a bug that could cause NULL pointer dereferences when COMP_WORDBREAKS
was unset.
2. Changes to Readline
3. New Features in Bash
a. A value of 0 for the -t option to `read' now returns success if there is
input available to be read from the specified file descriptor.
b. CDPATH and GLOBIGNORE are ignored when the shell is running in privileged
mode.
c. New bindable readline functions shell-forward-word and shell-backward-word,
which m
Howto set a Readline variable (not in the init file!)?
Hello I'm looking for a way to set a Readline variable, but without editing the init (~/.inputrc or /etc/inputrc) file. E.g., I'd like to have set show-all-if-ambiguous on The thing is that I have to login to some remote server with a login that I share with other users and I don't want to impose my settings by saving my options in a file. I tried bind set show-all-if-ambiguous on but this leads to a corrupted readline behaviour: I can't type anymore 's'. Reading the manual (http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins) it says explicitly (for the Builtin command 'bind'): "Display current Readline (see Command Line Editing) key and function bindings, bind a key sequence to a Readline function or macro, or set a Readline variable." I haven't find any example so far, so I'm thankful for any help or pointer. regards andi Andi Bachmann Department of Geography, University of Zurich
Re: Howto set a Readline variable (not in the init file!)?
Andi Bachmann wrote: > Hello > > I'm looking for a way to set a Readline variable, but without editing > the init (~/.inputrc or /etc/inputrc) file. > > E.g., I'd like to have > >set show-all-if-ambiguous on > > The thing is that I have to login to some remote server with a login > that I share with other users and I don't want to impose my settings by > saving my options in a file. > > I tried > > bind set show-all-if-ambiguous on > > but this leads to a corrupted readline behaviour: I can't type anymore 's'. > > Reading the manual > (http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins) it > says explicitly (for the Builtin command 'bind'): > >"Display current Readline (see Command Line Editing) key and > function bindings, bind a key sequence to a Readline function or > macro, or set a Readline variable." According to the man, you should pass the readline binding or variable as a single argument to bind (or at least that's what the example shown seems to imply), so: bind 'set show-all-if-ambiguous on' The above line seems to do the trick for me. -- D.
Re: command not found magic
On Thu, Dec 04, 2008 at 09:37:58AM +, Stephane Chazelas wrote:
> On Thu, Dec 04, 2008 at 10:16:20AM +0100, Roman Rakus wrote:
> > probably you heard about this topic. It is invoked by ubuntu guys. See
> > https://launchpad.net/ubuntu/+spec/command-not-found-magic
> > I would like to know, what do you think about it. It needs a small change
> > in bash.
> [...]
>
> A note about it. If ever it makes it to bash, maybe a good idea
> would be to call the handler command_not_found_handler instead
> of command_not_found_handle as it seems to make more sense (at
> least to me) and that's what zsh has chosen (for the same
> reason). See http://www.zsh.org/mla/workers/2007/msg00592.html
> So that one could use the same rc file for bash and zsh.
I'd second that. Here's a patch for bash-4.0-rc1:
--- config-top.h.orig 2009-01-12 13:41:45.0 -0900
+++ config-top.h2009-01-12 13:54:46.0 -0900
@@ -96,5 +96,5 @@
/* This is used as the name of a shell function to call when a command
name is not found. If you want to name it something other than the
- default ("command_not_found_handle"), change it here. */
-/* #define NOTFOUND_HOOK "command_not_found_handle" */
+ default ("command_not_found_handler"), change it here. */
+/* #define NOTFOUND_HOOK "command_not_found_handler" */
--
Ken Irving, fn...@uaf.edu, 907-474-6152
Water and Environmental Research Center
Institute of Northern Engineering
University of Alaska, Fairbanks
Re: Bash-4.0-rc1 available for FTP
Chet Ramey wrote: f. Changed behavior so the shell now acts as if it received an interrupt when a pipeline is killed by SIGINT while executing a list. Does this mean that $ sleep 60 ; do-something ...will no longer run 'do-something' when ctrl-C'd? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)
Re: Bash-4.0-rc1 available for FTP
Matthew Woehlke wrote: > Chet Ramey wrote: >> f. Changed behavior so the shell now acts as if it received an interrupt >> when a pipeline is killed by SIGINT while executing a list. > > Does this mean that > $ sleep 60 ; do-something > ...will no longer run 'do-something' when ctrl-C'd? Yes. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash-4.0-rc1 available for FTP
Chet Ramey wrote: Matthew Woehlke wrote: Chet Ramey wrote: f. Changed behavior so the shell now acts as if it received an interrupt when a pipeline is killed by SIGINT while executing a list. Does this mean that $ sleep 60 ; do-something ...will no longer run 'do-something' when ctrl-C'd? Yes. Cool :-). Thanks for that enhancement! -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html)
execution hook
Hi All, I was looking for a way to run a program prior to bash executing the program. Does anyone know of a hook that can do this, such as an environment that hold this hook value. -- View this message in context: http://www.nabble.com/execution-hook-tp21425515p21425515.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: execution hook
eneville_ wrote: > I was looking for a way to run a program prior to bash executing the > program. Does anyone know of a hook that can do this, such as an environment > that hold this hook value. Look at the documentation for BASH_ENV in the bash manual. When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following com- mand were executed: if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi but the value of the PATH variable is not used to search for the file name. Bob
