Re: BASH_SUBSHELL documentation misleading
Le 23/03/2011 20:28, Chet Ramey a écrit : > On 3/23/11 4:15 PM, Sam Liddicott wrote: > >> Yes. But a new subshell environment has been spawned. Each time that >> happens BASH_SUBSHELL should increase. >> >> Of course I know how it does work, but the man page isn't clear. It doesn't >> say that the increase is only visible within the subshell and therefore it >> is a measurement of subshell depth. > > OK. What wording would you like to see? > I would also like to see this example in the documentation: $ ( echo sub-$BASH_SUBSHELL ); echo main-$BASH_SUBSHELL sub-1 main-0 This example answers all doubts raised in this discussion. It also hints at the fact that: ( echo 'sub-$BASH_SUBSHELL' ) does not work like an inexperienced quoter could wrongly assume.
Re: BASH_SUBSHELL documentation misleading
On Thu, Mar 24, 2011 at 02:33:19PM +, Marc Herbert wrote: > I would also like to see this example in the documentation: > > $ ( echo sub-$BASH_SUBSHELL ); echo main-$BASH_SUBSHELL > sub-1 > main-0 Overkill. Most of the other features in the manual do not have such examples, and if we added examples of this size for every single feature, the manual would swell up to a tremendous size. It's already quite large. It should be enough to say that BASH_SUBSHELL is a subshell depth counter, incremented in each new subshell. > This example answers all doubts raised in this discussion. It also > hints at the fact that: > > ( echo 'sub-$BASH_SUBSHELL' ) > > does not work like an inexperienced quoter could wrongly assume. imadev:~$ ( echo 'sub-$BASH_SUBSHELL' ) sub-$BASH_SUBSHELL What did you expect?
Re: BASH_SUBSHELL documentation misleading
Le 24/03/2011 14:50, Greg Wooledge a écrit : > On Thu, Mar 24, 2011 at 02:33:19PM +, Marc Herbert wrote: >> I would also like to see this example in the documentation: >> >> $ ( echo sub-$BASH_SUBSHELL ); echo main-$BASH_SUBSHELL >> sub-1 >> main-0 > > Overkill. Tradeoff. > Most of the other features in the manual do not have such > examples, and if we added examples of this size for every single feature, > the manual would swell up to a tremendous size. It's already quite large. Not every feature is complicated enough that it requires special documentation care and that it raises a discussion here.
Re: BASH_SUBSHELL documentation misleading
On Thu, Mar 24, 2011 at 06:07:33PM +, Marc Herbert wrote: > Not every feature is complicated enough that it requires special > documentation care and that it raises a discussion here. BASH_SUBSHELL isn't complicated at all. It's just documented in a confusing way. It doesn't require an example to say that it reports the current subshell depth. It's just that the existing documentation can be interpreted to make someone think that it tracks a running total of how many subshells were created as children of the current shell in the past. That's where Sam got mixed up.
Using alias to commands disables its completion
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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 -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux guttp 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.1 Patch Level: 7 Release Status: release Description: When an alias is supplied to a command (e.g: alias c="cd") the complete doesn't complete like it used when using the original text, without using alias (e.g $ c # returns all files, not just directories) It doesn't seem to have any technical issue problem to make the detection of completion also by using alias (as when is hit the alias are also interpreted). Repeat-By: $ alias c="cd" $ c # suppose to only show directories, but it shows every file
Re: Using alias to commands disables its completion
On 03/24/2011 10:54 AM, Gustavo Serra Scalet wrote: > Description: > When an alias is supplied to a command (e.g: alias c="cd") the > complete doesn't complete like it used when using the original text, > without > using alias (e.g $ c # returns all files, not just > directories) > > It doesn't seem to have any technical issue problem to make the > detection of > completion also by using alias (as when is hit the alias are > also > interpreted). The lame answer: But you can already do this yourself! Write a shell function around alias, that calls both 'command alias' to do the real work, as well as 'complete -p' on the first word of new expansion then 'complete ...' on the new alias name, so that you copy any completion properties tied to the old name over to the new name. As long as you define your programmable completions before your aliases as part of your ~/.bashrc startup sequence, then this works. Even better, submit that as an enhancement request to the bash-completion project to have bash-completion provide that wrapper around alias provided automatically as part of starting up bash-completion. The answer you sort of wanted: Yes, it would be nice to patch to bash's completion routines to add an opt-in ability to check for programmed completion associated with whatever the alias expanded to, and use that when there is no completion already associated with the aliased name. But someone has to write such a patch. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: BASH_SUBSHELL documentation misleading
On Fri, Mar 25, 2011 at 2:17 AM, Greg Wooledge wrote: > On Thu, Mar 24, 2011 at 06:07:33PM +, Marc Herbert wrote: > > Not every feature is complicated enough that it requires special > > documentation care and that it raises a discussion here. > > BASH_SUBSHELL isn't complicated at all. It's just documented in a > confusing way. It doesn't require an example to say that it reports the > current subshell depth. It's just that the existing documentation > can be interpreted to make someone think that it tracks a running total > of how many subshells were created as children of the current shell in > the past. That's where Sam got mixed up. > > Agree. It's not complicated compared to, for example, =~ usage. :) -- Clark J. Wang
