typeset -r prevents local variable of same name.
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux saturn.syslang.net 2.6.27.41-170.2.117.fc10.i686.PAE #1 SMP
Thu Dec 10 10:48:30 EST 2009 i686 athlon i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
First, I already submitted this bug from work, but I didn't
realize that the address I sent from would not be allowed to receive
a response. This address will work fine.
If I declare a variable at the top scope using -r, it will prevent me
from declaring a local copy in a subroutine. This problem happens in
this version of bash as well as in bash4 under Fedora 14.
Repeat-By:
Here is a foo.sh that demonstrates the problem:
511 > cat foo.sh
#! /bin/bash
bar()
{
typeset abc="$1"
echo "abc:$abc"
}
typeset -r abc='Hello'
bar Goodbye
512 > ./foo.sh
./foo.sh: line 4: typeset: abc: readonly variable
abc:Hello
513 >
Here's another one that works and shows that top scope is the problem:
515 > cat foo2.sh
#! /bin/bash
baz()
{
typeset qwerty="$1"
typeset -r abc=wahoo
echo "qwertyabc:$qwerty$abc"
}
bar()
{
typeset abc="$1"
echo "abc:$abc"
}
bar Goodbye
baz ttt
515 > ./foo2.sh
abc:Goodbye
qwertyabc:tttwahoo
516 >
This makes it hard to define routines with local variables if you
don't know what variables are declared globally. The problem happens
with -r but does not seem to happen with -i or -a.
Am I missing something?
TIA
Steven W. Orr
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
Re: [BUG] Bash not reacting to Ctrl-C
On 02/11, Linus Torvalds wrote:
>
> @@ -2424,6 +2425,18 @@ wait_for (pid)
> sigaction (SIGCHLD, &oact, (struct sigaction *)NULL);
> sigprocmask (SIG_SETMASK, &chldset, (sigset_t *)NULL);
> # endif
> + /* If the waitchld returned EINTR, and the shell got a SIGINT,
> + then the child has not died yet, and we assume that the
> + child has blocked SIGINT. In that case, we require that the
> + child return with WSIGTERM() == SIGINT to actually consider
> + the ^C relevant. This is racy (the child may be in the
> + process of exiting and bash reacted to the EINTR first),
> + but this makes the race window much much smaller */
OK, I leave this up to you and Chet. At least the race is documented.
Another problem, child_blocked_sigint can be false positive if the
signal was sent to bash directly (not to pgrp). This means that the
next ^C won't work again.
And,
> + if (r == -1 && errno == EINTR && wait_sigint_received)
> + {
> + child_blocked_sigint = 1;
> + }
This can't work afaics. waitchld() can never return -1 && EINTR.
Perhaps waitchld() can set this flag, I don't know...
3087/* If waitpid returns 0, there are running children. If it
returns -1,
3088 the only other error POSIX says it can return is EINTR. */
3089CHECK_TERMSIG;
3090if (pid <= 0)
3091 continue; /* jumps right to the test */
The code looks strange btw. "jumps right to the test" is correct, but
this code does
do {
...
} while ((sigchld || block == 0) && pid > (pid_t)0);
and this "continue" in fact means "break". So, perhaps, we can do
if (pid < 0) {
if (wait_sigint_received)
child_blocked_sigint = 1;
break;
}
Oleg.
how to workaroun 'nl' being added to input-line after 49 characters....
I'm having a problem, I think, due to my setting the prompt in
'root' mode, to a different color. This results in me being able to
enter only 49 characters on the input line before it wraps to the next
line.
I add an open and close sequence to the normal prompt (which has no
weird problems with changing the input line length):
#specific to linux console compat emulations
_CRed="$(echo -en "\033[31m")" #Red
_CRST="$(echo -en "\033[0m")" #Reset
_CBLD="$(echo -en "\033[1m")" #Bold
export _prompt_open=""
export _prompt_close=">"
[[ $UID -eq 0 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="#$_CRST"
}
export PS1='${_prompt_open}$(spwd "$PWD")${_prompt_close} ';
Is there some easy way to tell bash either to not keep track of what it
thinks is the screen width (and just allow it to wrap, if that's
possible), or to reset bash's idea of where it thinks it is on the line?
Thanks!
Linda
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Linda Walsh wrote:
> I'm having a problem, I think, due to my setting the prompt in
> 'root' mode, to a different color. This results in me being able to
> enter only 49 characters on the input line before it wraps to the next
> line.
It sounds like you have forgotten to enclose non-printing characters
in your prompt with \[...\].
>#specific to linux console compat emulations
>_CRed="$(echo -en "\033[31m")" #Red
>_CRST="$(echo -en "\033[0m")" #Reset
>_CBLD="$(echo -en "\033[1m")" #Bold
>export _prompt_open=""
>export _prompt_close=">"
>[[ $UID -eq 0 ]] && {
>_prompt_open="$_CBLD$_CRed"
>_prompt_close="#$_CRST"
>}
>export PS1='${_prompt_open}$(spwd "$PWD")${_prompt_close} ';
>
> Is there some easy way to tell bash either to not keep track of what
> it thinks is the screen width (and just allow it to wrap, if that's
> possible), or to reset bash's idea of where it thinks it is on the
> line?
The bash manual says:
PROMPTING
\[ begin a sequence of non-printing characters, which could
be used to embed a terminal control sequence into the
prompt
\] end a sequence of non-printing characters
Therefore you want something like:
_CRed="$(echo -en "\033[31m")" #Red
_CRST="$(echo -en "\033[0m")" #Reset
_CBLD="$(echo -en "\033[1m")" #Bold
export _prompt_open=""
export _prompt_close=">"
[[ $UID -eq 1000 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="#$_CRST"
}
export PS1='\[${_prompt_open}\]$(pwd "$PWD")\[${_prompt_close}\] ';
But I didn't test the above.
Bob
Re: how to workaroun 'nl' being added to input-line after 49 characters....
On Sun, Feb 13, 2011 at 3:50 PM, Linda Walsh wrote:
> I'm having a problem, I think, due to my setting the prompt in
> 'root' mode, to a different color. This results in me being able to
> enter only 49 characters on the input line before it wraps to the next
> line.
>
> I add an open and close sequence to the normal prompt (which has no
> weird problems with changing the input line length):
>
>
> #specific to linux console compat emulations
> _CRed="$(echo -en "\033[31m")" #Red
> _CRST="$(echo -en "\033[0m")" #Reset
> _CBLD="$(echo -en "\033[1m")" #Bold
> export _prompt_open=""
> export _prompt_close=">"
> [[ $UID -eq 0 ]] && {
> _prompt_open="$_CBLD$_CRed"
> _prompt_close="#$_CRST"
> }
> export PS1='${_prompt_open}$(spwd "$PWD")${_prompt_close} ';
>
> Is there some easy way to tell bash either to not keep track of what it
> thinks is the screen width (and just allow it to wrap, if that's possible),
> or to reset bash's idea of where it thinks it is on the line?
>
> Thanks!
> Linda
>
>
>
>
Here's another way to do it:
#specific to linux console compat emulations
_CRed='\[\033[31m\]' #Red
_CRST='\[\033[0m\]' #Reset
_CBLD='\[\033[1m\]' #Bold
export _prompt_open=""
export _prompt_close=">"
[[ $UID -eq 0 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="#$_CRST"
}
export PS1="${_prompt_open}$(spwd "$PWD")${_prompt_close} "
Note the simplification of the variable assignments and the change in
quotes in the final command. Also, it's probably not necessary to do
any of those exports.
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Dennis Williamson writes: > _CRed='\[\033[31m\]' #Red > _CRST='\[\033[0m\]' #Reset > _CBLD='\[\033[1m\]' #Bold _CRed="\\[$(tput setaf 1)\\]" _CRST="\\[$(tput sgr0)\\]" _CBLD="\\[$(tput bold)\\]" Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Thanks for all the great suggestions on how to do the encoding differently -- how about ideas on the input line length being truncated? ;-) Andreas Schwab wrote: Dennis Williamson writes: _CRed='\[\033[31m\]' #Red _CRST='\[\033[0m\]' #Reset _CBLD='\[\033[1m\]' #Bold _CRed="\\[$(tput setaf 1)\\]" _CRST="\\[$(tput sgr0)\\]" _CBLD="\\[$(tput bold)\\]" Andreas.
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Linda Walsh wrote: > Thanks for all the great suggestions on how to do the > encoding differently -- how about ideas on the input line > length being truncated? You seem to have misunderstood. Each and every one of those response has addressed your issue of input line length problems. The solution to your line length problems is that you need to wrap non-printable characters such as your color sequences in quoted square brackets in order for readline to know that you are emitting non-printable characters. Otherwise it will count them as having taken up a column. This is what all of the discussion around the \[...\] has been about. Unless I have completely misunderstood your problem but I don't think so. Bob
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Bob Proulx wrote: Linda Walsh wrote: Thanks for all the great suggestions on how to do the encoding differently -- how about ideas on the input line length being truncated? You seem to have misunderstood. --- Actually, I saw the two rewrites first as they were sent via Personal mail and list mail, and I see personal mail in my Inbox, first, usually while list email I read by opening the corresponding bug-bash folder.(i.e. email sorted as it comes in direct address ->Inbox, list->list-folders) But anyway, something else is is awry. Now my root prompt, instead of being red, looks like: "\[\033[1m\]\[\033[31m\]Ishtar:root#\[\033[0m\] " ;-/ What version of bash has the \[ \] characters to keep it from counting chars?
Re: how to workaroun 'nl' being added to input-line after 49 characters....
Linda Walsh wrote:
> But anyway, something else is is awry.
>
> Now my root prompt, instead of being red, looks like:
>
> "\[\033[1m\]\[\033[31m\]Ishtar:root#\[\033[0m\] "
>
> ;-/
That will be due to incorrect quoting. Which suggestion did you
implement? There were several.
> What version of bash has the \[ \] characters to keep it from
> counting chars?
All of them.
Try this *exactly* as I post it. I did test this. It probably isn't
optimal. But it does what you are asking. And it is only a slight
variation from what you are currently using.
_CRed=$(tput setaf 1) #Red
_CRST=$(tput sgr0) #Reset
_CBLD=$(tput bold) #Bold
_prompt_open=""
_prompt_close=""
_prompt=">"
[[ $UID -eq 0 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="$_CRST"
_prompt="#"
}
PS1='\[$_prompt_open\]$(pwd "$PWD")$_prompt\[$_prompt_close\] ';
Bob
Here strings and pathname expansion
Hello world,
I recently answered a question about using the asterisk mixed with
redirection and other words. This also lead me to the documentation that
states (REDIRECTION section):
---
The word following the redirection operator in the following
descriptions, unless otherwise noted, is subjected to brace expansion,
tilde expansion, parameter expansion, command substitution, arithmetic
expansion, quote removal, pathname expansion, and word splitting. If it
expands to more than one word, bash reports an error.
---
This is true, for here documents the exceptions are mentioned. However,
for here strings no exceptions are mentioned ("The WORD is expanded
[...]]", but the WORD is at least not subject to pathname expansion:
$ cat <<< *
*
This is EITHER
(a) a documentation mistake OR
(b) a bug
Case (a) is clear, the exception is not mentioned.
Case (b) is also possible, because it COULD be intended to
pathname-expand WORD:
(1) error out if pathname expansion results in more than one word OR
(2) use the first word of the result OR
(3) pass all results (as a special case)
I would expect the thing to either be (a) or (b)(2).
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
