On 11/18/19 1:10 PM, Jim Monte wrote:
Thanks again for looking at these reports. I have thankfully essentially
completed my implementation of history for ngspice (an open-source
successor to SPICE 3F5 with a csh-like front end that handles parsing a bit
differently than a shell would), so I bel
On 11/18/19 12:40 PM, Jim Monte wrote:
Thank you for looking into all of these reports. My issue here was that in
both cases there had not yet been any ?string? search, so they should
behave the same way -- an event is not required to not have a most recent
?string? search. So if the default is
On 11/6/19 10:21 AM, Jim Monte wrote:
Another documentation issue for :s, and a bug, or two bugs, although it
seems to be one of each. Instead of "Any delimiter may be used in place of
‘/’.", it should be clarified that any character may be used in place of
'/' as a delimiter, although if '&' is
Thanks again for looking at these reports. I have thankfully essentially
completed my implementation of history for ngspice (an open-source
successor to SPICE 3F5 with a csh-like front end that handles parsing a bit
differently than a shell would), so I believe this report will be the final
one.
J
Thank you for looking into all of these reports. My issue here was that in
both cases there had not yet been any ?string? search, so they should
behave the same way -- an event is not required to not have a most recent
?string? search. So if the default is to use an empty string as the
previous str
On 11/6/19 8:04 AM, Jim Monte wrote:
Regarding the & word modifier, it would be useful to note in the
documentation that it applies the previous substitution whether it had been
successful or not, as shown below.
I don't think there's a need to qualify "previous substitution" here.
--
``The ly
On 11/5/19 11:44 AM, Jim Monte wrote:
The availability of the % string only after a command unrelated to it (not
using !??) is executed as shown below is not documented, but it probably
falls under the category of a bug. That is, it seems reasonable that both
echo "!%" commands should behave as t
On 11/4/19 9:42 AM, Jim Monte wrote:
Related to the issues with the ? event designator, the %word designator
substitutes the *first* word matched by the ? event designator or nothing
if the match begins with a space. These details are not documented.
Thanks. The issue is that, unlike csh, bash
On 11/3/19 9:18 AM, Jim Monte wrote:
Two more documentation issues I have found are below.
It appears that an empty substring event designator uses the string of the
previous substring event designator if none is provided and does not find
the event if there is no previous string.
Thanks for t
On 10/10/19 10:35 PM, Jim Monte wrote:
There is an inconsistency with the documentation and behavior of the ^ word
designator. According to documentation, it refers to the first argument but
does not require a ':' before it if it starts the word designator. However,
it does not act like the nume
On 10/3/19 6:19 PM, Jim Monte wrote:
=
Documentation of the :h and :t modifiers in section 9.3.3 is incomplete.
:h removes the last / and everything after it if a / is present. Otherwise
it does nothing.
:t removes eve
On 10/3/19 6:19 PM, Jim Monte wrote:
Description:
=
Documentation of quick substitution is incorrect (or does not match
behavior).
I believe this issue is an error with the documentation of history
"Quick Substitution"
host ~]# echo !:s//1/
>>>> bash: :s//1/: no previous substitution
>>>>
>>>> Again, this behavior is not documented.
>>>>
>>>> On Thu, Oct 10, 2019 at 10:35 PM Jim Monte
>>>> wrote:
>>>>
>>>>> Hi,
>>>&g
esignator. According to documentation, it refers to the first
>>>> argument but does not require a ':' before it if it starts the word
>>>> designator. However, it does not act like the numerical word designator 1
>>>> at the end of a range.
>>>>
However, it does not act like the numerical word designator 1
>>> at the end of a range.
>>>
>>> [root@localhost ~]# echo a b c
>>> a b c
>>> [root@localhost ~]# echo !!:1-1
>>> echo a
>>> a
>>> [root@localhost ~]# echo a b
ented that :- is equivalent to :0-
>>
>> [root@localhost ~]# echo a b c d
>> a b c d
>> [root@localhost ~]# echo !!:-
>> echo echo a b c
>> echo a b c
>> [root@localhost ~]# echo a b c d
>> a b c d
>> [root@localhost ~]# echo !!:0-
>> echo e
substitution. I am duplicating
>> its behavior in a somewhat different use, and found issues with the
>> documentation and bugs as described.
>>
>> Jim Monte
>>
>>
>>
>>
>> From: jim
>> To: bug-bash@gnu.org
>> Subject: Issues with
On 10/3/19 6:19 PM, Jim Monte wrote:
> Hi All,
>
> Below are some issues I found with history substitution. I am duplicating
> its behavior in a somewhat different use, and found issues with the
> documentation and bugs as described.
Thanks for the report. I haven't looked at these yet.
--
``Th
described.
>
> Jim Monte
>
>
>
>
> From: jim
> To: bug-bash@gnu.org
> Subject: Issues with history substitution and its documentation
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler:
Hi All,
Below are some issues I found with history substitution. I am duplicating
its behavior in a somewhat different use, and found issues with the
documentation and bugs as described.
Jim Monte
From: jim
To: bug-bash@gnu.org
Subject: Issues with history substitution and its documentation
20 matches
Mail list logo
