Re: [PATCH] Support configurable mode strings in prompt
Hi Chet, Just curious if it will be possible to merge this enhancement? Thanks, Dylan
Re: [PATCH] Support configurable mode strings in prompt
On 9/4/14, 7:22 AM, Dylan Cali wrote: > Hi Chet, > > Just curious if it will be possible to merge this enhancement? I haven't looked at it yet. -- ``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: "source" cmd creates entry in BASH_SOURCE etc. only if within function
On 9/2/14, 2:59 PM, jim.av...@gmail.com wrote:
> Bash Version: 4.3
> Patch Level: 0
> Release Status: release
>
> Description:
>
> The "source" (or ".") command, if invoked from within a function,
> creates a call frame, setting $FUNCNAME[0] to "source" and
> $BASH_SOURCE[1] and $BASH_LINENO[1] to the location of the "source"
> statement.
>
> However this does not occur if the "source" statement occurs in
> mainline code, i.e. outside of any function.
This is true. The FUNCNAME variable is not visible outside functions, so
the assignment of `source' to FUNCNAME, which was done primarily for the
bash debugger's convenience, doesn't have any effect when outside a
function.
>
> This means that code in "sourced" files can not reliably
> display the location of their call, i.e., the location of
> the "source" (or ".") statement which invoked them.
But this is not. If you want to see where the sourced file was invoked,
use ${BASH_SOURCE[1]}:${BASH_LINENO} or the `caller' builtin.
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/
RFE: remove duplicate entries from the result of `compgen -W'
See following example: $ echo $BASH_VERSION 4.3.18(1)-release $ compgen -W 'hello hello' h hello hello $ It'll be good if only one "hello" is outputted. -clark
Re: SEGFAULT if bash script make "source" for itself
2014-09-03 7:31 GMT-07:00 Chet Ramey : > On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote: > > IMHO any user action should not lead to SIGSEGV! I am not objecting > against > > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no > > idea why this is happened. I have made recursive "sourse" by mistake and > > spend a lot of time looking up what exactly lead to SIGSEGV. > > > > Put a configurable limit on the deep of recursive source. There is almost > > no variant for legal usage of recursive source on deep... 1 for > > example. If someone need such recursion deep, he alway can raise limit or > > turn it off by setting it to 0. > > This is more or less the way I am leaning. In the next version of bash, it > will be possible to set a limit on the number of recursive source/. or eval > calls at compile time. This will be accomplished by changing a define in > config-top.h. There will be no limit enabled by default. > > Why "define"? Why not variable like "FUNCNEST" for functions? Most part of this mailing list tell me about inadmissibility any limits in gnu soft... And SIGSEVG in interpreter is only end user problem. An here is limit on compile time. :) > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ >
