On Sat, Mar 18, 2017 at 3:21 PM, Chet Ramey wrote:
> How would you suggest capturing this in the documentation in a way that
> would be clearer? The text from your previous message or something else?
I'm finding it hard to come up with a concise and accurate description
of the behavior since the
On 3/21/17 4:27 PM, Peter & Kelly Passchier wrote:
> On 22/03/2560 01:32, Martijn Dekker wrote:
>> A workaround for the original poster's problem could be:
>>
>> (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
>
> 'unset -f jobs' is not guaranteed to unset jobs, it might set jobs to a
> fu
On 22/03/2560 01:32, Martijn Dekker wrote:
> A workaround for the original poster's problem could be:
>
> (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
'unset -f jobs' is not guaranteed to unset jobs, it might set jobs to a
function definition in an earlier scope..!
On 3/21/17 11:51 AM, Grisha Levit wrote:
> The new optimized assignment in the devel branch that is used when
> appending to a string has a bug with the way READLINE_LINE is checked
> in bash_execute_unix_command:
Thanks for the report. Please keep looking for other instances of this.
Chet
--
`
On Tue, Mar 21, 2017 at 11:59 AM, Chet Ramey wrote:
>> As a special case, `fc -l -0' usually prints itself but not in the
>> empty history (or HISTSIZE=1) case.
>
> Yeah, that's a special case, but not when there are no commands in
> the history list.
Thanks for the explanation. FWIW my less-dege
On 3/21/17 2:38 PM, Greg Wooledge wrote:
> On Tue, Mar 21, 2017 at 07:32:27PM +0100, Martijn Dekker wrote:
>> A workaround for the original poster's problem could be:
>>
>> (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
>>
>> The 'eval' is to stop the alias from being expanded at parse tim
On Tue, Mar 21, 2017 at 07:32:27PM +0100, Martijn Dekker wrote:
> A workaround for the original poster's problem could be:
>
> (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
>
> The 'eval' is to stop the alias from being expanded at parse time before
> you have a chance to unalias it. T
Op 21-03-17 om 18:08 schreef Greg Wooledge:
> A builtin is always used by preference over an external command of the
> same name. You don't need to specify "builtin jobs" to be sure you're
> using the builtin. Just use "jobs".
>
> The only time you need to use the "builtin" command is when you'r
On 03/21/2017 12:08 PM, Greg Wooledge wrote:
> The code that makes bash behave differently when "jobs" is one of the
> commands in a pipeline/subshell is kind of a hack. It's probably not
> extremely well known outside of this mailing list, but I suspect many
> people have used it without realizi
Hi Greg,
Thanks for your explanation! Now it solved my problem. I did misuse the
"builtin" builtin when using "jobs". Now I only need to enforce that "jobs"
is "enabled", which is not a walkaround :-)
Except one thing that bothers me a tiny bit is that, how about I wrote a
"jobs" function and sti
On Tue, Mar 21, 2017 at 04:53:59PM +, Hengyang Zhao wrote:
> But back to the user's perspective, as I looked up "help jobs" or "help
> builtin", the sematics of "builtin" is only for forcing the shell to use
> the builtin version, right? Actually, I was writing a script that needs to
> secure t
Dear Chet,
Thanks for your reply and I apologyze for the mistake I made in the "buggy
behavior" section.
I didn't realize that a builtin is forced to run in a subshell until you
told me. Yes, as I tried, "jobs" consumes no PID, but even "jobs | true"
consumes two. I'll look into the code followin
On 3/21/17 11:35 AM, Grisha Levit wrote:
> If the history is empty (or if HISTSIZE is 1) running `fc -l' produces an
> error:
>
> $ history -c
> $ fc -l
> bash: fc: history specification out of range
fc deals with the commands in the history list before the `fc' (that's
what the `pre
The new optimized assignment in the devel branch that is used when
appending to a string has a bug with the way READLINE_LINE is checked
in bash_execute_unix_command:
v = bind_variable ("READLINE_LINE", rl_line_buffer, 0);
l = v ? value_cell (v) : 0;
# parse_and_execute ...
v = f
2017-03-20 16:32:10 -0400, Chet Ramey:
[...]
> > See also:
> >
> > $ bash -c 'f() { unset a; echo "$a";}; a=1; a=2 f'
> > 1
> >
> > already mentioned.
>
> A distinction without a difference; the behavior is explicitly the same.
[...]
One I haven't mentioned yet is:
$ bash -c 'f() { local a; un
On Mon, 20 Mar 2017 18:29:07 -0400,
Eduardo Bustamante wrote:
>
> This was reported a month ago:
> http://lists.gnu.org/archive/html/bug-bash/2017-02/msg00025.html
Oh! Thank you, I tried searching the list archives, but nothing came
up. Odd; it shows up in searches now.
--
Happy hacking,
~ Luk
If the history is empty (or if HISTSIZE is 1) running `fc -l' produces an error:
$ history -c
$ fc -l
bash: fc: history specification out of range
I'm not sure this is necessary, since other instances of `first' and
`last' being outside of the saved history range don't produce an
erro
On 3/20/17 7:47 PM, Hengyang Zhao wrote:
> Hello,
>
> I am experiencing an unexpected behavior when using "builtin jobs -l". It
> seems that it's output fd is not as same as "jobs -l" without the builtin
> prefix. So when I piped it into wc, I got different results (as seen in the
> code I pasted
Hello,
I am experiencing an unexpected behavior when using "builtin jobs -l". It
seems that it's output fd is not as same as "jobs -l" without the builtin
prefix. So when I piped it into wc, I got different results (as seen in the
code I pasted below).
Bash version: GNU bash, version 4.3.43(1)-re
On 3/20/17 6:52 PM, D630 wrote:
> I get an infinite error loop in B, and I suppose that's not because of my
> settings.
It's not. This will be fixed in the next devel branch push.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' -
On 03/18/2017 12:19 PM, Chet Ramey wrote:
> On 3/17/17 6:35 PM, Dan Douglas wrote:
>
>> The problem is the non-obvious nature of unset's interaction with scope,
>> (and the lack of documentation). Not much can be done about the former,
>> as it is with so many things.
>
> How would you suggest im
21 matches
Mail list logo
