On jue, 20-08-2015 a las 17:38 -0700, Linda Walsh wrote:
> Functions are a collection of many commands. They are not a single,
> simple statement. I remember using their return value in some cases.
>
> With the change, I couldn't run a func and have it return the
> value in $? (1 byte, I know) -
On 8/20/15 8:38 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>>> The earlier spec had -e only exit a script if a *simple* (external)
>>> command failed. It didn't include builtins nor functions.
>>
>> This is not; builtins and functions are simple commands.
> ---
> The builtins are _complex_ b
Chet Ramey wrote:
The earlier spec had -e only exit a script if a *simple* (external)
command failed. It didn't include builtins nor functions.
This is not; builtins and functions are simple commands.
---
The builtins are _complex_ binary blobs that replace external commands.
Functions are
On 8/19/15 5:58 PM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>>
>> (Wow, how did we get here from "-e does not take effects in subshell"?)
>>
> ---
> because the POSIX spec changed and bash's handling of "-e"
> changed to follow t
erve-root extension, as you pointed out,
I don't see what would stop them from adding another extension to permit
GNUrm -rfx . to work. Perhaps you should come up with an appropriate
syntax for it and submit a patch to the GNU coreutils maintainers. This
is not related to bash.
(Wow, how did we get here from "-e does not take effects in subshell"?)
Greg Wooledge wrote:
(Wow, how did we get here from "-e does not take effects in subshell"?)
---
because the POSIX spec changed and bash's handling of "-e"
changed to follow the new spec.
The earlier spec had -e only exit a script if a *simple* (external)
command f
Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
When did POSIX or any historical U
Andreas Schwab wrote:
Linda Walsh writes:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
Now rm will delete things on any number of file systems, as long
as they
Linda Walsh writes:
> Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
> -x switch like 'find, cp, mv, et al.) no longer works to clean
> out a directory && stay on *one* file system.
>
> Now rm will delete things on any number of file systems, as long
> as they correspond to a
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
> Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
> -x switch like 'find, cp, mv, et al.) no longer works to clean
> out a directory && stay on *one* file system.
When did POSIX or any historical Unix rm have a --one-f
Eric Blake wrote:
Like it or not, it is the historical behavior standardized by POSIX.
This is not true. POSIX no longer documents historical behavior,
but now dictates new, historically-incompatible behaviors for a
variety of features in a variety of products (not just BASH).
As such,
On 8/13/15 1:35 AM, isabella parakiss wrote:
> On 8/13/15, Eric Blake wrote:
>> Like it or not, it is the historical behavior standardized by POSIX. It
>> is NOT intuitive, and our advice is "DON'T USE set -e - IT WON'T DO WHAT
>> YOU WANT". We can't change the behavior, because it would break sc
On 8/13/15, Eric Blake wrote:
> Like it or not, it is the historical behavior standardized by POSIX. It
> is NOT intuitive, and our advice is "DON'T USE set -e - IT WON'T DO WHAT
> YOU WANT". We can't change the behavior, because it would break scripts
> that rely on the POSIX-specified behavior.
On 08/12/2015 09:54 PM, PRC wrote:
> 1. If the function is complicated and contains lots of commands, it
> would be more troublesome appending && to every command rather
> than simply using one single "set -e" at the front.
> 2. It is not
> reasonable that suppression of '-e' is applied as wel
function. My intention is if my_build succeeds continue to do other
stuff. Does anyone like the rule that a function never fails only if it is part
of a
compound command?
> Date: Tue, 11 Aug 2015 09:50:56 -0400
> From: wool...@eeg.ccf.org
> To: ijk...@msn.com
> CC: bug-bash@gnu.org
&g
On Tue, Aug 11, 2015 at 11:42:29AM +, PRC wrote:
> mybuild()
> {
> (
> set -e
> make
> echo "build okay"
> )
> }
>
> mybuild && do_other_stuff
http://mywiki.wooledge.org/BashFAQ/105
Since mybuild is invoked as part of a compound command, set -e is
suppressed.
I have a export function looking like:
mybuild()
{
(
set -e
make
echo "build okay"
)
}
I wish to use this function this way:
mybuild && do_other_stuff
But whatever (success or failure) make returns "build okay" is always printed
and do_other_stuff always gets ex
17 matches
Mail list logo
