David Lehmann wrote:
The ((i++)) fails only when the result is 1.
---
What are you calling the result? The return value or
the post-incremented value of 'i', which is done *after* the
return-result is returned?
I.e. you are talking 2 different point of return (that's one
issue). Second, o
Ken Irving wrote:
On Sun, Aug 18, 2013 at 06:30:47PM -0700, Linda Walsh wrote:
Chet Ramey wrote:
On 8/14/13 7:44 AM, Andreas Gregor Frank wrote:
Hi,
i think a file_not_found_handle() or a modified command_not_found_handle(),
that does not need an unsuccessful PATH search to be triggered, wo
Chet Ramey wrote:
On 8/19/13 1:52 PM, Linda Walsh wrote:
That explains it... There's -- in searching the output, I'm
pretty sure that seeing a stray '!' in the left hand margin
wouldn't have looked like a var.
In this case, especially for the 1 char vars, wouldn't it be
easier to help people
Hi Chet,
sorry, i thought you talk about the bash code.
I didn't want to show my own usecase but now i have to ;-):
I have a File class and can construct a File "object" for example:
File anObjectName /etc/passwd
and then i can do
e.g. anObjectName.getInode (this already works with
command_not_fou
I actually had that problem as well, I found the description in the end
it just took longer than I expected.
Sent from my BlackBerry 10 smartphone.
From: Linda Walsh
Sent: Monday, August 19, 2013 19:53
To: bug-bash
Subject: Re: child_pid of background process? (not in manpage
On 8/19/13 6:57 AM, Andreas Gregor Frank wrote:
> Hi Chet,
>
> I have no idea if there is "enough" demand, but i think there will be some
> ideas to use this feature...
> I still think it is a question of consistency to be able to handle a "No
> such file or directory event", if i can do this with
On 8/18/13 9:30 PM, Linda Walsh wrote:
>> A PATH search is suppressed when the command to be executed contains a
>> slash: the presence of a slash indicates an absolute pathname that is
>> directly passed to exec(). Since there's no search done, you know exactly
>> which pathname you're attemptin
On 8/19/13 1:52 PM, Linda Walsh wrote:
>
>
> Chris Down wrote:
>> On 2013-08-18 17:46, Linda Walsh wrote:
>>> I don't find the variable for the process ID of the
>>> last started background process documented in the bash manpage...
>>>
>>> Am I just missing it, or did it get left out by accident
Chris Down wrote:
On 2013-08-18 17:46, Linda Walsh wrote:
I don't find the variable for the process ID of the
last started background process documented in the bash manpage...
Am I just missing it, or did it get left out by accident or
where did it go?
First of all, it would help if you gav
On 2013-08-19 07:42, Greg Wooledge wrote:
> A long time ago I submitted a patch that would change all of these to
> include their $ so that people could SEARCH for them and FIND them,
> but the patch was not accepted.
I support this patch.
pgptg7YdQPdN5.pgp
Description: PGP signature
On Mon, Aug 19, 2013 at 05:53:03AM +0200, Chris Down wrote:
> On 2013-08-18 17:46, Linda Walsh wrote:
> > I don't find the variable for the process ID of the
> > last started background process documented in the bash manpage...
> >
> > Am I just missing it, or did it get left out by accident or
> >
On Mon, Aug 19, 2013 at 05:50:31AM +0200, Chris Down wrote:
> On 2013-08-18 16:57, David Lehmann wrote:
> > The ((i++)) fails only when the result is 1. When the result is 0 or 2, it
> > does not fail. This is a problem when 'set -e'.
>
> This is normal and expected. If the value returned in an
Hi Chet,
I have no idea if there is "enough" demand, but i think there will be some
ideas to use this feature...
I still think it is a question of consistency to be able to handle a "No
such file or directory event", if i can do this with a "command not found
event" (independent of the command_not
David Lehmann writes:
> ! grep hello x
! causes the shell to ignore -e.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
14 matches
Mail list logo
