Re: cannot declare local variables if they're readonly
On 7/23/15, Chet Ramey wrote:
> This is an excellent time to point out that it's to everyone's advantage
> to be as complete as possible when describing a problem on the list,
> rather than revealing additional details one at a time.
>
> There's no way anyone would have guessed that you were encountering this
> with BASH_REMATCH; the most likely possibility was that you were trying to
> override a variable you had declared readonly.
>
> Yes, BASH_REMATCH is special. It's not present by default, and it is
> destroyed and reconstituted fresh every time you use the =~ operator to
> [[, since it's only supposed to exist if something matched. I suppose
> there's no real reason to make it readonly other than that there's no real
> reason to write to it, and =~ is the only thing that can modify it.
> Removing the restriction on local copies of readonly variables wouldn't do
> a thing to change the BASH_REMATCH semantics, though it would allow scripts
> to unset it. We would need a different discussion about how you'd like
> BASH_REMATCH to work.
>
No. Don't minimize this, it's not only about BASH_REMATCH.
The fact that a certain special variable is readonly for no real reason
doesn't change this absurd nonsense about any other global variable.
In one thread you linked in your previous answer, you explained that it
could be a security hole if an admin sets a readonly global variable for
some package, then a new function comes in, changes that value, and then
invokes that package with the new environment.
Consider this stupid example:
fib () {
local first=$1 second=$2 sum
sum=$(( first + second ))
if (( first < 123456 )); then
fib "$second" "$sum"
echo "$first"
fi
}
It seems to work just fine:
$ fib 1 1
121393
75025
But it suddenly breaks if first is a readonly global variable.
$ readonly first
$ fib 1 1
bash: local: first: readonly variable
bash: local: first: readonly variable
What's the solution for this? Naming conventions such as fib_local_first?
(Of course that example doesn't even need to declare variables and could
just use $1 and $2 but that's not the point, real scripts do need them)
Is this *not* a security hole?
---
xoxo iza
Re: cannot declare local variables if they're readonly
On 7/23/15 10:57 AM, isabella parakiss wrote: > On 7/23/15, Greg Wooledge wrote: >> People who use "readonly" are generally doing so in the context of a >> "restricted shell" (yes, commence laughter) or other situation where >> that specific variable is the key to unlocking something that the >> administrator does not want the user to unlock. The entity who used >> "readonly" is presumed to want that variable to remain unchanged, forever. > > On 7/23/15, Stephane Chazelas wrote: >> 2015-07-23 01:12:01 +0200, isabella parakiss: >> What that means is that with this kind of dynamic scoping, >> "readonly" is not very helpful. I don't remember ever using it. > > You guys are assuming that I am the one who uses readonly. > I'm not, *bash* is. This is an excellent time to point out that it's to everyone's advantage to be as complete as possible when describing a problem on the list, rather than revealing additional details one at a time. There's no way anyone would have guessed that you were encountering this with BASH_REMATCH; the most likely possibility was that you were trying to override a variable you had declared readonly. Yes, BASH_REMATCH is special. It's not present by default, and it is destroyed and reconstituted fresh every time you use the =~ operator to [[, since it's only supposed to exist if something matched. I suppose there's no real reason to make it readonly other than that there's no real reason to write to it, and =~ is the only thing that can modify it. Removing the restriction on local copies of readonly variables wouldn't do a thing to change the BASH_REMATCH semantics, though it would allow scripts to unset it. We would need a different discussion about how you'd like BASH_REMATCH to work. -- ``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: Segfault in save_bash_input. Array index is out of a range.
On 7/22/15 5:00 PM, Alexey Makhalov wrote:
> I have met situation when nfd(returned by fcntl) is 217, but nbuffers is
> only 25
>
> if (buffers[nfd])
> {
> /* What's this? A stray buffer without an associated open file
> descriptor? Free up the buffer and report the error. */
> internal_error (_("save_bash_input: buffer already exists for new fd
> %d"), nfd);
> free_buffered_stream (buffers[nfd]);
> }
> and free_buffered_stream() causes a segfault.
Thanks, this is a good fix.
> I added extra comparison nfd < nbuffers - it works for me.
> Why do we need this check? Does stray buffer happen, when nfd is in a range
> [0,nbuffers)?
I forget the exact reason, but I'm sure I ran into that situation in the
past. It's more robust programming, at least.
--
``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: echo redirect additional new line
On Thu, Jul 23, 2015 at 11:01:46AM -0400, Greg Wooledge wrote: echo 2>"c\nd" Did you intend to write the number "2" to a file, or did you intend to redirect stderr? ... The space after the 2 is extremely significant, and $'...' is how you create strings (filenames, etc.) with control characters in them. Oh, I am sorry. Thank you for the explanation. Best regards, Hans
Re: cannot declare local variables if they're readonly
On Thu, Jul 23, 2015 at 04:57:42PM +0200, isabella parakiss wrote:
> The fact is, I found out this by using BASH_REMATCH, trying to use it in
> different functions without interfering with each other.
Ah! That changes things. :)
imadev:~$ [[ x =~ y ]]
imadev:~$ declare -p BASH_REMATCH
declare -ar BASH_REMATCH='()'
imadev:~$ f() { local BASH_REMATCH; [[ y =~ z ]]; } ; f
bash: local: BASH_REMATCH: readonly variable
Chet will have to address this further.
Re: echo redirect additional new line
On Thu, Jul 23, 2015 at 03:41:13PM +0200, Hans Ginzel wrote: > Hello! > > Consider, please, this small script > > echo 1 > echo 1>"a b" > echo 2 > echo 2>"c\nd" Did you intend to write the number "2" to a file, or did you intend to redirect stderr? > Why is there the additional new line between 2 and 3 or 3 and 4 > respectively. Because you are redirecting stderr instead of stdout. echo is writing to stdout, and it has no arguments, so stdout just gets a blank line. You are redirecting stderr to a file named c\nd (that's four characters, one of which is a literal backslash), but nothing is being written to stderr, so the file is 0 bytes long. I believe you probably wanted: echo 2 >$'c\nd' The space after the 2 is extremely significant, and $'...' is how you create strings (filenames, etc.) with control characters in them.
Re: cannot declare local variables if they're readonly
On 7/23/15, Greg Wooledge wrote:
> People who use "readonly" are generally doing so in the context of a
> "restricted shell" (yes, commence laughter) or other situation where
> that specific variable is the key to unlocking something that the
> administrator does not want the user to unlock. The entity who used
> "readonly" is presumed to want that variable to remain unchanged, forever.
On 7/23/15, Stephane Chazelas wrote:
> 2015-07-23 01:12:01 +0200, isabella parakiss:
> What that means is that with this kind of dynamic scoping,
> "readonly" is not very helpful. I don't remember ever using it.
You guys are assuming that I am the one who uses readonly.
I'm not, *bash* is.
The fact is, I found out this by using BASH_REMATCH, trying to use it in
different functions without interfering with each other.
And it did work, sometimes. I couldn't even reproduce it in a new shell.
It turns out that bash-completion uses it. And why wouldn't they?
So my functions stopped working because I tried to... tab complete strace?
WOW. This makes so much sense.
I imagine that people want to be able to use something like this:
extract_package () {
local BASH_REMATCH
if [[ $1 =~ (.*)-([0-9]+\.[0-9]+)\.tar.gz ]]; then
tar xf "$1"
if install_package; then
echo "${BASH_REMATCH[1]} ${BASH_REMATCH[2]} successfully installed"
else
echo "Couldn't install ${BASH_REMATCH[1]} ${BASH_REMATCH[2]}"
fi
fi
}
install_package () {
local BASH_REMATCH
some legit use of [[ =~ ]]
}
Anyway for some reason that I don't fully understand, the above won't even
work when BASH_REMATCH is not defined, as shown below.
$ declare -p BASH_REMATCH
bash: declare: BASH_REMATCH: not found
$ f () { local BASH_REMATCH; [[ abc =~ .(.*). ]]; g; declare -p BASH_REMATCH; }
$ g () { local BASH_REMATCH; [[ xyz =~ .(.*). ]]; }
$ f
bash: declare: BASH_REMATCH: not found
$ f
bash: local: BASH_REMATCH: readonly variable
bash: local: BASH_REMATCH: readonly variable
declare -ar BASH_REMATCH='([0]="xyz")'
$
To sum it up: for some reason that you can't control, local variables may
or may not be assigned correctly. Also don't use local BASH_REMATCH
because it doesn't work.
Bash is a very usable language and this is totally not a problem.
---
xoxo iza
echo redirect additional new line
Hello! Consider, please, this small script echo 1 echo 1>"a b" echo 2 echo 2>"c\nd" echo 3 echo 3>"`echo -e 'e\nf'`" echo 4 The output is 1 2 3 4 Why is there the additional new line between 2 and 3 or 3 and 4 respectively. bash --version GNU bash, version 4.3.11(1)-release (i686-pc-linux-gnu) Regards Hans
Re: cannot declare local variables if they're readonly
On 7/22/15 7:12 PM, isabella parakiss wrote: > From variables.c > >The test against old_var's context > level is to disallow local copies of readonly global variables (since I > believe that this could be a security hole). > > Can you please explain how that can be a security hole? http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00194.html http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00099.html -- ``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: cannot declare local variables if they're readonly
2015-07-23 01:12:01 +0200, isabella parakiss:
> From variables.c
>
>The test against old_var's context
> level is to disallow local copies of readonly global variables (since I
> believe that this could be a security hole).
>
> Can you please explain how that can be a security hole?
>
>
> $ readonly wtf; fn () { local wtf; }; fn
> bash: local: wtf: readonly variable
>
> You can't even be sure that you can set *local* variables in a function.
> This is a problem.
>
> Most of the shells that support local variables (ksh93, mksh, zsh, dash...)
> allow this. The only one I could find that doesn't is busybox.
[...]
I agree with you. That was discussed on another list a few
months ago. Unfortunately Chet seems to be of a different
opinion:
http://www.zsh.org/mla/workers/2015/msg00924.html
To be fair, you also need to consider cases like:
readonly c=299792458
light_year() {
REPLY=$((c * 86400 * 365))
}
my_func() {
local a=1 b=2 c=3
light_year "$((a + b + c))"
}
What that means is that with this kind of dynamic scoping,
"readonly" is not very helpful. I don't remember ever using it.
--
Stephane
Re: cannot declare local variables if they're readonly
On Thu, Jul 23, 2015 at 01:12:01AM +0200, isabella parakiss wrote: > From variables.c > >The test against old_var's context > level is to disallow local copies of readonly global variables (since I > believe that this could be a security hole). > > Can you please explain how that can be a security hole? People who use "readonly" are generally doing so in the context of a "restricted shell" (yes, commence laughter) or other situation where that specific variable is the key to unlocking something that the administrator does not want the user to unlock. The entity who used "readonly" is presumed to want that variable to remain unchanged, forever. A typical example is PATH. I am not advocating this security model. I'm just explaining the rationale.
