Chet Ramey wrote:
On 8/7/11 6:03 PM, Linda Walsh wrote:
Bash itself is inconsistent in that it accepts exit values the same as
every other
program, but limits return values to a particular subset.
Bash accepts any value you want to give to `return' and strips it to
8 bits, as the standard all
On 8/7/11 7:02 PM, Curtis Doty wrote:
> On Sun, 7 Aug 2011, Chet Ramey wrote:
>
>> On 8/7/11 6:00 PM, Curtis Doty wrote:
>>> local job jobcount=0
>>> while read job
>>> do ((jobcount++))
>>> done < <(jobs)
>>
>> As you suspect, the problem is with this part of the function. It doesn't
>>
On Sun, 7 Aug 2011, Chet Ramey wrote:
On 8/7/11 6:00 PM, Curtis Doty wrote:
local job jobcount=0
while read job
do ((jobcount++))
done < <(jobs)
As you suspect, the problem is with this part of the function. It doesn't
really have anything to do with PROMPT_COMMAND, though. You must
Linda Walsh wrote:
> Bob Proulx wrote:
> >Exit codes should be in the range 0-255.
> ---
> I suppose you don't realize that 'should' is a subjective opinion that
> sometimes has little to do with objective reality.
Sigh. Okay. Keep in mind that turn about is fair play. You are
giving it t
On 8/7/11 6:00 PM, Curtis Doty wrote:
> I've recently refactored my PROMPT_COMMAND function to avoid superfluous
> fork()s. In the body of the function, what was once this line:
>
> local jobcount=$(jobs |wc -l)
>
> is now this:
>
> local job jobcount=0
> while read job
> do ((jobcount++
On 8/7/11 6:03 PM, Linda Walsh wrote:
> Bash itself is inconsistent in that it accepts exit values the same as
> every other
> program, but limits return values to a particular subset.
Bash accepts any value you want to give to `return' and strips it to
8 bits, as the standard allows. Read the e
On 8/7/11 4:35 PM, Linda Walsh wrote:
> ---
> How about portable code using:
>
> (exit -1); return
return $(( -1 & 255 ))
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduh
Bob Proulx wrote:
Linda Walsh wrote:
How about portable code using:
(exit -1); return
It's ugly, but would seem to be the portable/official way to
do this.
Exit codes should be in the range 0-255.
---
I suppose you don't realize that 'should' is a subjectiv
I've recently refactored my PROMPT_COMMAND function to avoid superfluous
fork()s. In the body of the function, what was once this line:
local jobcount=$(jobs |wc -l)
is now this:
local job jobcount=0
while read job
do ((jobcount++))
done < <(jobs)
This works fine on bash 4. However,
Linda Walsh wrote:
> How about portable code using:
>
> (exit -1); return
>
> It's ugly, but would seem to be the portable/official way to
> do this.
Exit codes should be in the range 0-255.
Bob
Eric Blake wrote:
On 08/05/2011 05:41 PM, Linda Walsh wrote:
Seem to fail on any negative number, but 'exit status' is defined
as a short int -- not an unsigned value (i.e. -1 would return 255).
In bash, 'return -- -1' sets $? to 255 (note the --). But since that is
already an extension (P
Geir Hauge wrote:
2011/7/25 Linda Walsh
I know it wasn't designed this way, but it seems like it
is a bug.
The manual says nothing about brace expansion using IFS in any way, so it's
not a bug.
I didn't say the manual said that.
However, in expanding arrays you have the
I'm running shell script that will often run 'unattended' (batch),
however, for testing and future flexablity, I wish to add an **option**
(cmdline
arg) to, after defining the utils of the lib, enter normal interactive mode,
so the user could invoke the library calls from the cmdline, set or
I have a bash completion file (see below)
It works fine, but i would like add a feature => not expand the flag by
a space when it contain '='
curently when i do:
$ ldc2 -Df
ldc2 -Df=⊔
i would like:
ldc2 -Df
ldc2 -Df=
without space
tanks a lot
---
# bash completion for ldc
_ldc()
14 matches
Mail list logo
