Re: Assignments to FUNCNAME break FUNCNAME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/14 7:53 PM, Arfrever Frehtes Taifersar Arahesis wrote: > Manual of BASH claims: > "Assignments to FUNCNAME have no effect and return an error status." > > However assignments to FUNCNAME actually break FUNCNAME. > I use BASH 4.3.30. Thanks for the report. This will be fixed in the next release of bash. Chet - -- ``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/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlR5OQcACgkQu1hp8GTqdKujJgCglR7/B4gKu4H60UMOxpwt698O TloAnAo6E1pUwcmRSeXt3bNsxiSmsnWM =2sBz -END PGP SIGNATURE-
Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/28/14 5:38 PM, Askar Safin wrote: >> There are only a couple of ways to do this, so even though the mechanism >> konsole uses is undocumented, we can try to figure it out. There are two >> possibilities: inject a character into the input stream, or send a signal >> to the foreground process group. > I tested this. This is not some symbol in input stream (tested using "stty > raw -echo; cat > /tmp/log"). And this is signal 28, i. e. SIGWINCH (on Debian > GNU/Linux amd64, tested using small C program). Also, a small test C program, > which uses readline (Debian version 6.2+dfsg-0.1) works as I expect. > > So, yes, this is not bash+konsole bug, this is readline+konsole bug. No. You have missed the point. The point is that the secret mechanism that konsole used to use no longer works. It didn't rely on documented behavior; it relied on a side effect of the (flawed) readline-6.2 implementation. It can't really be called a bug. >> There is a better explanation in one of the threads I referenced in my >> previous message, but here's the short story: readline has always set >> SIGWINCH to restart system calls. It would redraw the prompt upon receipt >> of a SIGWINCH in previous versions because it (incorrectly) executed that >> code in a signal handler context. Cleaning up the code so it didn't try >> to execute arbitrary code in signal handlers was one of the big changes >> between bash-4.2/readline-6.2 and bash-4.3/readline-6.3. > So, is this possible to restore old behavior in bash-4.3/readline-6.3 > preserving "clean" and "right" code? Not in its current form, no. If you read the threads I referred to in the previous message, you will see this message, which lays out the problem pretty clearly: http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00070.html In another message, you'll find: "You have to think about the difference between a signal that interrupts a system call, like SIGALRM, and a signal like SIGWINCH that does not. If the system call isn't interrupted, readline doesn't have an opportunity to do anything until it returns. I can look at changing readline so that a SIGWINCH interrupts system calls, but I will have to look at the code more before doing it. Having system calls interrupted in unexpected places leads to hard-to-find problems, and SIGWINCH is supposed to be transparent. I will play around with it." While there have been some interesting ideas proposed, the easiest way to make this sort of dyamism possible is to keep SIGWINCH from restarting system calls by default. I have to evaluate the possible consequences of doing that, since, as I said, it leads to hard-to-reproduce problems. > ATTENTION! Now I want to report some REAL BUG! When I change konsole size > with some long text line typed in bash 4.2 buffer, text moves. With bash 4.3 > it doesn't move. :) > Yes, I know, nobody uses Ctrl-Shift-X except for me, so, you think this > Ctrl-Shift-X-bug isn't worth fixing. But everybody resize his terminal > window, so now I found real bug, ahaha! :) > Reproduces using 4.3-11 from Debian and doesn't reproduce using > 4.2+dfsg-0.1+deb7u3 from Debian. And thank you, Chet for the idea. :) You have not identified a bug in readline, you have identified a bug in konsole. konsole apparently expects that sending a stream of SIGWINCHes to the foreground process is enough to force redisplay. Other terminal emulators, like Mac OS X Terminal, manage to make redisplay work in this case. chet -- ``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: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/28/14 8:17 PM, Askar Safin wrote: >>> Also, is there somewhere some real revision control system with bash >>> sources? http://git.savannah.gnu.org/cgit/bash.git appears to be >>> incomplete: "git bisect" shows that the problem is in >>> http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 >>> , but this is a huge commit. Where can I download more detailed history? >> >> Try looking at the devel branch. > Thanks. > http://git.savannah.gnu.org/cgit/bash.git/commit/?id=f4f5e1c2b8fa4539e367e1f48774183d349184c5 > in devel branch is commit which introduces this behavior (git bisect, again). > But still this branch doesn't seem as real devel history. This is just weekly > snapshots. Does bash have real SCM (non-git ones is OK)? Where is SCM you use > for development? I use something local and home-grown that far predates git. The development history is a combination of the change log (CWRU/CWRU.chlog) and the git devel checkins. -- ``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[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
>> Also, is there somewhere some real revision control system with bash >> sources? http://git.savannah.gnu.org/cgit/bash.git appears to be >> incomplete: "git bisect" shows that the problem is in >> http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 >> , but this is a huge commit. Where can I download more detailed history? > >Try looking at the devel branch. Thanks. http://git.savannah.gnu.org/cgit/bash.git/commit/?id=f4f5e1c2b8fa4539e367e1f48774183d349184c5 in devel branch is commit which introduces this behavior (git bisect, again). But still this branch doesn't seem as real devel history. This is just weekly snapshots. Does bash have real SCM (non-git ones is OK)? Where is SCM you use for development? == Askar Safin
Assignments to FUNCNAME break FUNCNAME
Manual of BASH claims:
"Assignments to FUNCNAME have no effect and return an error status."
However assignments to FUNCNAME actually break FUNCNAME.
I use BASH 4.3.30.
Variant with "local":
$ A() { echo A; declare -p FUNCNAME; local FUNCNAME=(); }
$ B() { echo B; declare -p FUNCNAME; }
$ A
A
declare -a FUNCNAME='([0]="A")'
bash: FUNCNAME: variable may not be assigned value
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A")'
bash: FUNCNAME: variable may not be assigned value
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A" [2]="A")'
bash: FUNCNAME: variable may not be assigned value
$ B
B
declare -a FUNCNAME='([0]="B" [1]="A" [2]="A" [3]="A")'
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A" [2]="A" [3]="A")'
bash: FUNCNAME: variable may not be assigned value
$ B
B
declare -a FUNCNAME='([0]="B" [1]="A" [2]="A" [3]="A" [4]="A")'
$
Variant without "local":
$ A() { echo A; declare -p FUNCNAME; FUNCNAME=(); }
$ B() { echo B; declare -p FUNCNAME; }
$ A
A
declare -a FUNCNAME='([0]="A")'
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A")'
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A" [2]="A")'
$ B
B
declare -a FUNCNAME='([0]="B" [1]="A" [2]="A" [3]="A")'
$ A
A
declare -a FUNCNAME='([0]="A" [1]="A" [2]="A" [3]="A")'
$ B
B
declare -a FUNCNAME='([0]="B" [1]="A" [2]="A" [3]="A" [4]="A")'
$
Also is it intentional that code after attempt of assignment to FUNCNAME is not
run?
The sentence in manual could be interpreted as simply setting $? to non-zero
value and still running subsequent code.
$ A() { echo A; local FUNCNAME=(); echo AAA; }
$ A
A
bash: FUNCNAME: variable may not be assigned value
$
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
>There are only a couple of ways to do this, so even though the mechanism >konsole uses is undocumented, we can try to figure it out. There are two >possibilities: inject a character into the input stream, or send a signal >to the foreground process group. I tested this. This is not some symbol in input stream (tested using "stty raw -echo; cat > /tmp/log"). And this is signal 28, i. e. SIGWINCH (on Debian GNU/Linux amd64, tested using small C program). Also, a small test C program, which uses readline (Debian version 6.2+dfsg-0.1) works as I expect. So, yes, this is not bash+konsole bug, this is readline+konsole bug. >Since typing ^L at the prompt works, that's probably not what konsole uses. Yes, ^L works. Also, konsole 2.8.4 (upstream version, default in wheezy) (this is version I use) uses Ctrl-Shift-X as default shortcut for "Clear Scrollback and Reset" and konsole 2.14.2 (upstream version, default in sid as on today) uses Ctrl-Shift-K. >This would make sense if the two operations did the same thing. I don't >think they do; I think the Ctrl-Shift-X key sequence causes konsole to >send SIGWINCH. I still want Ctrl-Shift-X to work as in 4.2. ^_^ >There is a better explanation in one of the threads I referenced in my >previous message, but here's the short story: readline has always set >SIGWINCH to restart system calls. It would redraw the prompt upon receipt >of a SIGWINCH in previous versions because it (incorrectly) executed that >code in a signal handler context. Cleaning up the code so it didn't try >to execute arbitrary code in signal handlers was one of the big changes >between bash-4.2/readline-6.2 and bash-4.3/readline-6.3. So, is this possible to restore old behavior in bash-4.3/readline-6.3 preserving "clean" and "right" code? ATTENTION! Now I want to report some REAL BUG! When I change konsole size with some long text line typed in bash 4.2 buffer, text moves. With bash 4.3 it doesn't move. :) Yes, I know, nobody uses Ctrl-Shift-X except for me, so, you think this Ctrl-Shift-X-bug isn't worth fixing. But everybody resize his terminal window, so now I found real bug, ahaha! :) Reproduces using 4.3-11 from Debian and doesn't reproduce using 4.2+dfsg-0.1+deb7u3 from Debian. And thank you, Chet for the idea. :) == Askar Safin http://vk.com/safinaskar Kazan, Russia
Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/28/14 10:34 AM, Askar Safin wrote: >> Doesn't seem like a bug to me. You asked your terminal emulator to clear >> the screen. It did so. Now you complain that it's "too clean" :) > When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should > work the same and it should clear scrollback additionally. > bash 4.3 + konsole behavior is not OK for me, because I have to press "Enter" > after Ctrl-Shift-X. :) This would make sense if the two operations did the same thing. I don't think they do; I think the Ctrl-Shift-X key sequence causes konsole to send SIGWINCH. >> I understand how it may look confusing, but I don't think the term has >> much option here. Suppose that instead of the shell, you were executing >> something else (eg. reading a log file). > Yes, but this somehow worked before. And I press Ctrl-Shift-X in bash only. :) There is a better explanation in one of the threads I referenced in my previous message, but here's the short story: readline has always set SIGWINCH to restart system calls. It would redraw the prompt upon receipt of a SIGWINCH in previous versions because it (incorrectly) executed that code in a signal handler context. Cleaning up the code so it didn't try to execute arbitrary code in signal handlers was one of the big changes between bash-4.2/readline-6.2 and bash-4.3/readline-6.3. > Also, is there somewhere some real revision control system with bash sources? > http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: "git > bisect" shows that the problem is in > http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 > , but this is a huge commit. Where can I download more detailed history? Try looking at the devel branch. Chet -- ``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: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
On 11/27/14 5:27 PM, Askar Safin wrote: > Steps to reproduce: open konsole (with bash in it) and type Ctrl-Shift-X > (this is shortcut for "Clear Scrollback and Reset" feature in konsole). What > I see: the terminal clears and no prompt appear. What I expected: I expected > prompt to appear. > > This is upstream bug, and it is a regression. It appeared in bash 4.3, but in > bash 4.2 there was no such bug. This isn't exactly a bug. It means that whatever secret mechanism konsole uses to try to force a prompt redisplay uses a feature that changed between bash-4.2 (readline-6.2) and bash-4.3. There are only a couple of ways to do this, so even though the mechanism konsole uses is undocumented, we can try to figure it out. There are two possibilities: inject a character into the input stream, or send a signal to the foreground process group. Since typing ^L at the prompt works, that's probably not what konsole uses. If it were going to inject a character into the input to force a screen clear, that would most likely be the one. The other possibility is sending a signal. The most likely candidate for this is SIGWINCH, since readline reacts to it but it's not usually trapped. If a user process had SIGWINCH trapped and konsole sent SIGWINCH in response to a key sequence, we'd probably be seeing more bug reports. SIGWINCH is not a great candidate for this, since readline sets things up so that it doesn't interrupt system calls like read or write. You don't really want a SIGWINCH to interrupt reads or writes (especially writes) even if you want to be notified of window size changes. It's also ignored by default, so if you're running something that doesn't install a handler for it, you probably won't see anything but a blank screen after a Ctrl-Shift-X. The behavior you've observed, though, is consistent with konsole sending bash a SIGWINCH and expecting it to handle the signal immediately regardless of what it might be doing. So it's probably SIGWINCH. And since readline is waiting to read input, and the SIGWINCH doesn't interrupt the read(2), there's nothing to tell readline that it should redisplay the prompt. Previous discussions of this topic: http://lists.gnu.org/archive/html/bug-readline/2014-05/msg5.html http://lists.gnu.org/archive/html/bug-bash/2014-05/msg00063.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/
Inconsistent behaviour of +=() and existing array keys
So, referring to man bash, this is the description of +=: When += is applied to an array variable using compound assignment (see Arrays below), the variable's value is not unset (as it is when using =), and new values are appended to the array beginning at one greater than the array's maximum index (for indexed arrays) or added as additional key-value pairs in an associative array. This description does not help us understand what should happen when this syntax explicitly mentions keys and more specifically, ones that already exist within the array. Intuition would likely have us believe that since +=() mutates the array by adding the elements to it, consistency would imply that when you specify elements by key, the array would either gain an element for that key or change the existing element at that key. So if we were to run this code: declare -a indexed_array=( [0]=a ) declare -A associative_array=( ["x"]=a ) indexed_array+=( [0]=b [1]=c ) associative_array+=( ["x"]=b ["y"]=c ) declare -p indexed_array associative_array Here's what I would expect to see: declare -a indexed_array='([0]="b" [1]="c")' declare -A associative_array='([x]="a" [y]="c" )' Instead, we get this: declare -a indexed_array='([0]="ab" [1]="c")' declare -A associative_array='([x]="ab" [y]="c" )' So the current behaviour appears to change the meaning of +=() as either mutating the array or mutating the array elements, depending on whether the specified key already exists within the array. I believe this behaviour to not only be counter-intuitive but also dangerous: the same syntax now has two distinct meanings depending solely on what data already exists within the array. Even more interestingly, it is apparently also legal to use the += operator within the element assignment syntax: indexed_array+=( [0]+=b [1]+=c ) This appears to behave exactly as a normal = would there. What I would expect is for += inside +=() to behave as = does now, and = to behave as it does outside of +=(), which is to "set" the value, not append. Ergo: declare -a indexed_array=( [0]=a ) indexed_array=( [0]=b ) #=> [0]=b -- because we unset the array and set the element so those given. indexed_array+=( [0]=b ) #=> [0]=b -- because we mutate the array by setting the element to that given. indexed_array=( [0]+=b ) #=> [0]=b -- because we unset the array and set the element by appending the given to nothing. indexed_array+=( [0]+=b ) #=> [0]=bb -- because we mutate the array by appending the given to what is already there. -- *Maarten Billemont* (lhunath) me: http://www.lhunath.com – business: http://www.lyndir.com – http://masterpasswordapp.com
Re: json + bash
On 11/27/14 11:25 PM, Sergei Tokaev wrote:
> Hi out there. Will it be good to add json support in bash internally. As
> in variable declarations: decalre "-j" "{"variable":"value"}"
Why? What advantage would be gained by doing this? Is there a large
number of developers wanting this feature? (Hint: no.)
Chet
--
``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[2]: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
>Doesn't seem like a bug to me. You asked your terminal emulator to clear >the screen. It did so. Now you complain that it's "too clean" :) When I type Ctrl-L, screen clears, and prompt appears. Ctrl-Shift-X should work the same and it should clear scrollback additionally. bash 4.3 + konsole behavior is not OK for me, because I have to press "Enter" after Ctrl-Shift-X. :) >I understand how it may look confusing, but I don't think the term has >much option here. Suppose that instead of the shell, you were executing >something else (eg. reading a log file). Yes, but this somehow worked before. And I press Ctrl-Shift-X in bash only. :) >PS: While I agree that what you are considering a bug is not >Debian-specific, I don't think you had enough data at bug submission >time to ascertain that this was an upstream bug (specially not knowing >which was the upstream provider). However, you did a good job describing >the bug report itself. :) Reproduced with bash 4.3 built from upstream sources. And yes, konsole was from Debian. Also, is there somewhere some real revision control system with bash sources? http://git.savannah.gnu.org/cgit/bash.git appears to be incomplete: "git bisect" shows that the problem is in http://git.savannah.gnu.org/cgit/bash.git/commit/?id=ac50fbac377e32b98d2de396f016ea81e8ee9961 , but this is a huge commit. Where can I download more detailed history? == Askar Safin http://vk.com/safinaskar Kazan, Russia
Re: json + bash
On 28/11/14 13:02, Greg Wooledge wrote:
> On Fri, Nov 28, 2014 at 10:25:52AM +0600, Sergei Tokaev wrote:
>> Hi out there. Will it be good to add json support in bash internally. As
>> in variable declarations: decalre "-j" "{"variable":"value"}"
>
> This doesn't seem like an appropriate addition to bash, in my opinion.
> Where do you draw the line? Should bash also parse XML? Windows .INI
> files? Comma-separated-value text files with quotes around elements
> that contain commas? Apache-style log files with quotes around fields
> that contain spaces?
>
> In my opinion, all of those things are inappropriate to add to bash.
Agreed. For example to represent INI values in the shell one can:
$ eval $(crudini --get example.ini section)
That also does validation, like:
$ crudini --get git/crudini/example.ini non-sh-compat
space name
útf8name
1num
ls;name
$ crudini --get --format=sh git/crudini/example.ini non-sh-compat 1num
Invalid sh identifier: 1num
As for json, I see that the jq utility has the '@sh' formatter,
which I've not looked into but probably has a similar function.
thanks,
Pádraig.
Re: BASH_FUNC__ appearing in environment
On Friday, 28 November 2014 09:02:56 UTC, Geir Hauge wrote:
> 2014-11-28 9:43 GMT+01:00 steveT :
>
>
> OK - found the functions that are appearing. I was grepping BASH_FUNC__ in
> etc - wrong. The functions are in the /usr/share/bash-completion/completions
> directory - and exist as rcs and sudo files. The code in those files defines
> functions for _rcs and _sudo respectively. The rcs file contains:
>
>
>
> # bash completion for rcs -*- shell-script
> -*-
>
>
>
> _rcs()
>
> {
> [--snipp--]
>
> } &&
>
> complete -F _rcs ci co rlog rcs rcsdiff
>
>
>
> # ex: ts=4 sw=4 et filetype=sh
>
>
>
> OK - so that is the code that appears in my environment as BASH_FUNC__rcs -
> now the question is - why - and why does it persist? I am not aware of using
> completion with sudo or rcs - so where/why/how in bash do these /usr/share
> scripts get actioned?
>
>
> The third-party bash-completion package sets a "default completion function"
> (see it with complete -p -D; declare -f _completion_loader) that dynamically
> loads completions. For instance, if you do
>
>
> $ rcs TAB
>
>
> And there is not already a completion loaded for rcs, It will look for
> /usr/share/bash-completion/completions/rcs, source it if it finds it, then
> use the new completion. This in itself will not cause the function to be
> exported. I can only think of two ways of the function being exported, and
> that's by
>
>
> 1. specifically exporting it with ''export -f _rcs'' or ''declare -xf _rcs''
>
> 2. you happen to run ''set -a'' at some point before the completion function
> gets dynamically loaded. When ''set -a'' is in effect, all variables and
> functions you define get automatically exported. If the output of ''echo
> "$-"'' contains 'a', then it is in effect.
>
> --
>
> Geir Hauge
Geir,
The set -a route must be it, as the echo shows -a being set and looking at the
.bash_profile , it uses set -a. Also - when using 'set', I don't see the rcs or
sudo completion being there, so presumably, at some point in my working day,
the rcs/sudo completion is loaded and because of the set -a, then appears in my
environment.
Thanks Geir and all for your help.
Re: json + bash
On Fri, Nov 28, 2014 at 10:25:52AM +0600, Sergei Tokaev wrote:
> Hi out there. Will it be good to add json support in bash internally. As
> in variable declarations: decalre "-j" "{"variable":"value"}"
This doesn't seem like an appropriate addition to bash, in my opinion.
Where do you draw the line? Should bash also parse XML? Windows .INI
files? Comma-separated-value text files with quotes around elements
that contain commas? Apache-style log files with quotes around fields
that contain spaces?
In my opinion, all of those things are inappropriate to add to bash.
Re: bash 4.3: "Clear Scrollback and Reset" (Ctrl-Shift-X) in konsole stopped to work as expected when upgrading from upstream bash 4.2 to upstream bash 4.3
Doesn't seem like a bug to me. You asked your terminal emulator to clear the screen. It did so. Now you complain that it's "too clean" :) I understand how it may look confusing, but I don't think the term has much option here. Suppose that instead of the shell, you were executing something else (eg. reading a log file). What would be the "right" behavior there? Its only option is to clear its "screen". If you know you were in a shell, and want the prompt to reappear, you only need to press enter after the reset. Best regards PS: While I agree that what you are considering a bug is not Debian-specific, I don't think you had enough data at bug submission time to ascertain that this was an upstream bug (specially not knowing which was the upstream provider). However, you did a good job describing the bug report itself. :)
json + bash
Hi out there. Will it be good to add json support in bash internally. As
in variable declarations: decalre "-j" "{"variable":"value"}"
smime.p7s
Description: Криптографическая подпись S/MIME
Re: BASH_FUNC__ appearing in environment
2014-11-28 9:43 GMT+01:00 steveT :
> OK - found the functions that are appearing. I was grepping BASH_FUNC__ in
> etc - wrong. The functions are in the /usr/share/bash-completion/completions
> directory - and exist as rcs and sudo files. The code in those files
> defines functions for _rcs and _sudo respectively. The rcs file contains:
>
> # bash completion for rcs -*-
> shell-script -*-
>
> _rcs()
> {
> [--snipp--]
> } &&
> complete -F _rcs ci co rlog rcs rcsdiff
>
> # ex: ts=4 sw=4 et filetype=sh
>
> OK - so that is the code that appears in my environment as BASH_FUNC__rcs
> - now the question is - why - and why does it persist? I am not aware of
> using completion with sudo or rcs - so where/why/how in bash do these
> /usr/share scripts get actioned?
>
The third-party bash-completion package sets a "default completion
function" (see it with complete -p -D; declare -f _completion_loader) that
dynamically loads completions. For instance, if you do
$ rcs TAB
And there is not already a completion loaded for rcs, It will look for
/usr/share/bash-completion/completions/rcs, source it if it finds it, then
use the new completion. This in itself will not cause the function to be
exported. I can only think of two ways of the function being exported, and
that's by
1. specifically exporting it with ''export -f _rcs'' or ''declare -xf _rcs''
2. you happen to run ''set -a'' at some point before the completion
function gets dynamically loaded. When ''set -a'' is in effect, all
variables and functions you define get automatically exported. If the
output of ''echo "$-"'' contains 'a', then it is in effect.
--
Geir Hauge
Re: BASH_FUNC__ appearing in environment
On Friday, 28 November 2014 08:00:18 UTC, steveT wrote:
> On Thursday, 27 November 2014 17:57:30 UTC, konsolebox wrote:
> > On Fri, Nov 28, 2014 at 12:36 AM, steveT steveT wrote:
> > > Is there any way that I can trace them back to their 'creator'?
> >
> > Besides checking common startup files like /etc/profile and ~/.profile or
> > ~/.bashrc (see
> > http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html),
> > you can also try to debug bash as it loads in login mode:
> >
> > # bash -lx &> out.txt
> > # exit
> >
> > Read out.txt, try to find those declarations and pay close attention to
> > lines before it that calls another file with . or source. If you don't
> > find any kind of declaration, it's likely that those functions are declared
> > somewhere during system init and that would depend on your init system.
> >
> > If it's me I'd just do fgrep something /etc -r (not -R unless I'm sure it's
> > safe) and see if I can find something useful. It may still not be enough
> > though - especially if those declarations are hard-coded in a binary
> > executable or data file. You can also consider searching through the files
> > of the base package of your init system - or even examine the sources if
> > you can.
> >
> > Cheers,
> > konsolebox
>
> Konsolebox,
> Thanks - I did try recursively grepping etc and didn't find anything.
> I will try the bash 'init' check, but I don't think it can be there as
> wouldn't that imply that the BASH_FUNC__ vars would be there from the outset?
> And, the BASH_FUNCs appear at random (obviously not random, as they must be
> being triggered by something) points during the day - I can go hours and not
> see these appear - I can use sudo and rcs to do various things and they don't
> appear.
>
> Can I ask - is there a chance that it's something that I've done in a script?
> Is there a setting somewhere that tells bash to export certain functions to
> the shell or do you have to explicitly export them to see them in the
> environment like this?
OK - found the functions that are appearing. I was grepping BASH_FUNC__ in etc
- wrong. The functions are in the /usr/share/bash-completion/completions
directory - and exist as rcs and sudo files. The code in those files defines
functions for _rcs and _sudo respectively. The rcs file contains:
# bash completion for rcs -*- shell-script -*-
_rcs()
{
local cur prev words cword
_init_completion || return
local file dir i
file=${cur##*/}
dir=${cur%/*}
# deal with relative directory
[[ $file == $dir ]] && dir=.
COMPREPLY=( $( compgen -f "$dir/RCS/$file" ) )
for (( i=0; i < ${#COMPREPLY[@]}; i++ )); do
file=${COMPREPLY[$i]##*/}
dir=${COMPREPLY[$i]%RCS/*}
COMPREPLY[$i]=$dir$file
done
COMPREPLY+=( $( compgen -G "$dir/$file*,v" ) )
for (( i=0; i < ${#COMPREPLY[@]}; i++ )); do
COMPREPLY[$i]=${COMPREPLY[$i]%,v}
done
# default to files if nothing returned and we're checking in.
# otherwise, default to directories
[[ ${#COMPREPLY[@]} -eq 0 && $1 == ci ]] && _filedir || _filedir -d
} &&
complete -F _rcs ci co rlog rcs rcsdiff
# ex: ts=4 sw=4 et filetype=sh
OK - so that is the code that appears in my environment as BASH_FUNC__rcs - now
the question is - why - and why does it persist? I am not aware of using
completion with sudo or rcs - so where/why/how in bash do these /usr/share
scripts get actioned?
Re: BASH_FUNC__ appearing in environment
On Thursday, 27 November 2014 17:57:30 UTC, konsolebox wrote: > On Fri, Nov 28, 2014 at 12:36 AM, steveT steveT wrote: > > Is there any way that I can trace them back to their 'creator'? > > Besides checking common startup files like /etc/profile and ~/.profile or > ~/.bashrc (see > http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html), > you can also try to debug bash as it loads in login mode: > > # bash -lx &> out.txt > # exit > > Read out.txt, try to find those declarations and pay close attention to > lines before it that calls another file with . or source. If you don't > find any kind of declaration, it's likely that those functions are declared > somewhere during system init and that would depend on your init system. > > If it's me I'd just do fgrep something /etc -r (not -R unless I'm sure it's > safe) and see if I can find something useful. It may still not be enough > though - especially if those declarations are hard-coded in a binary > executable or data file. You can also consider searching through the files > of the base package of your init system - or even examine the sources if > you can. > > Cheers, > konsolebox Konsolebox, Thanks - I did try recursively grepping etc and didn't find anything. I will try the bash 'init' check, but I don't think it can be there as wouldn't that imply that the BASH_FUNC__ vars would be there from the outset? And, the BASH_FUNCs appear at random (obviously not random, as they must be being triggered by something) points during the day - I can go hours and not see these appear - I can use sudo and rcs to do various things and they don't appear. Can I ask - is there a chance that it's something that I've done in a script? Is there a setting somewhere that tells bash to export certain functions to the shell or do you have to explicitly export them to see them in the environment like this?
