On 1/11/16 11:08 AM, Reuti wrote:
>> Yes. The output is intended to show how a name would be resolved if used
>> as a command. The order is
>>
>> alias
>> reserved word
>> function
>> builtin
>> command hash table
>> PATH search
>
> Great. May I suggest to add this
Surely a pipe counts as an explicit redirection?
And even if it didn't, the inconsistency between the first and subsequent
asynchronous elements is confusing.
On 12 Jan 2016 02:41, "Chet Ramey" wrote:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> > hey,
> >
> > I am quite sure it happens her
On 1/11/16 1:05 PM, Alastair Hughes wrote:
> Sorry, I meant that I had compiled bash without job control support, by
> adding 'bash_cv_job_control_missing=missing'
Got it. This will be fixed in the next release.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 1/11/16 3:37 PM, Chet Ramey wrote:
> On 1/11/16 3:29 PM, Martin Kealey wrote:
>> Surely a pipe counts as an explicit redirection?
>
> It doesn't.
I should be clear that this is according to what the standard says. The
existing code attempts to inhibit this implicit redirection in the
presence
On 1/11/16 3:29 PM, Martin Kealey wrote:
> Surely a pipe counts as an explicit redirection?
It doesn't.
> And even if it didn't, the inconsistency between the first and subsequent
> asynchronous elements is confusing.
Agreed.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Sorry, I meant that I had compiled bash without job control support, by adding
'bash_cv_job_control_missing=missing'
On 1/11/16 11:37 AM, Andreas Schwab wrote:
> Chet Ramey writes:
>
>> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
>>> hey,
>>>
>>> I am quite sure it happens here (devel branch, at
>>> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>>>
>>> execute_cmd.c +5115:
>>>if ((cmdflags & CMD_STDIN_REDIR)
Chet Ramey writes:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
>> hey,
>>
>> I am quite sure it happens here (devel branch, at
>> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>>
>> execute_cmd.c +5115:
>>if ((cmdflags & CMD_STDIN_REDIR) &&
>> pipe_in == NO_PIPE &&
>> (stdin_redirects
> Am 11.01.2016 um 15:52 schrieb Chet Ramey :
>
> On 1/9/16 2:12 PM, Reuti wrote:
>>
>> Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski:
>>
>>> hello Linda,
>>>
>>> On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote:
For what it's worth, It might be useful to have something like
>>>
On 1/9/16 8:16 PM, Alastair Hughes wrote:
> When job control is enabled:
> $ read < <(:); echo $?
> 1
> When job control is disabled:
> $ read < <(:); echo $?
> 0
When you say "job control is disabled", do you mean the shell is compiled
without job control support?
I get an exit status of
On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> hey,
>
> I am quite sure it happens here (devel branch, at
> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>
> execute_cmd.c +5115:
>if ((cmdflags & CMD_STDIN_REDIR) &&
> pipe_in == NO_PIPE &&
> (stdin_redirects (redirects) == 0))
> async_
On 1/10/16 3:50 PM, Linda Walsh wrote:
> Yeah, sorta but I want it to do variable expansion AND quote removal.
Then you do have to use eval with appropriate quoting.
> I.e. using a var or DQ of the object-name, "a", works in declare.
You should consider the difference between an argument to a s
On 1/9/16 8:28 PM, Linda Walsh wrote:
>Not in a function definition (i.e. this is broken AFAIAC in bash).
It's not.
> I.e.
>> 'func' () { :; }
> -bash: `'func'': not a valid identifier
>> function 'func' () { : ; }
> -bash: `'func'': not a valid identifier
>> function "func" () { :; }
> -
On 1/9/16 5:06 PM, Piotr Grzybowski wrote:
> On Sat, Jan 9, 2016 at 8:12 PM, Reuti wrote:
>>
>> AFAICS putting the name in quotes (single or double) will prefer the
>> function over the alias, but it will fall back to a command if there is no
>> function.
>>
>> 'P' params
>
> if Linda is ok wi
On 1/9/16 2:21 PM, Eric Cook wrote:
> In mksh, ksh93, zsh and maybe others, you can use quotes to suppress alias
> expansions during definition just like you would a simple command;
> unfortunately bash deems it a invalid identifier.
This is how Posix specifies it, and how the `base implementati
On 1/9/16 2:12 PM, Reuti wrote:
>
> Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski:
>
>> hello Linda,
>>
>> On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote:
>>>
>>> For what it's worth, It might be useful to have something like
>>> 'command' [..]
>>
>> that would be useful, a keyword like:
>>
On 1/8/16 4:01 PM, Piotr Grzybowski wrote:
> On Thu, Jan 7, 2016 at 9:32 PM, Chet Ramey wrote:
>> On 1/5/16 8:08 AM, Greg Wooledge wrote:
>>
>>> imadev:~$ zap me
>>> bash: zap: command not found
>>> imadev:~$ history -d -1
>>> bash: history: -1: history position out of range
>>> imadev:~$ history
On 1/7/16 11:21 PM, Eduardo A. Bustamante López wrote:
> BTW, the timestamp = 0 thing is a bug in readline. Since it uses (time_t) 0 as
> a return value for errors in history_get_time, and later there's code similar
> to this:
>
> t = history_get_time(...)
> if(t)
> strftime(...)
>
On 1/7/16 11:33 AM, Reuben Thomas wrote:
> Would it be better to have the default time for unmarked history lines to
> be the epoch rather than the current time?
It is circumstance-dependent. The default you propose would be appropriate
for your situation: a history file where you started maintai
19 matches
Mail list logo
