Chet Ramey wrote:
This is intended. Bash doesn't allow a local copy of a variable to
override a readonly global one. This can be a potential security hole,
---
You can look at it that way, but it also hinders modular programming.
If I declare a variable to be local, I wouldn't expect it t
Dennis Williamson wrote:
Aliases are intended for command line convenience. You should use
functions, which can be exported and are the correct thing to use in
scripts (and even from the command line).
"For almost every purpose, shell functions are preferred over aliases."
But, of course, yo
How can I export an alias so it survives across an exec?
I thought there was a way for them to be exported like vars or functions...
but neither work.
I have a prog that needs an alias defined, if it isn't, it
execs a program to define the alias which re-execs the first --
if the alias isn'
Greg Wooledge wrote:
On Wed, Apr 11, 2012 at 02:34:01AM -0700, Linda Walsh wrote:
- for ((vl=$((v_level - 1)); $vl > 0; --vl))
The inside of the for ((...)) is already a math context. You don't need
another $((...)) inside it.
for ((vl = v_level - 1; vl > 0; --vl))
Or is t
Chet Ramey wrote:
On 4/9/12 9:07 PM, Linda Walsh wrote:
** linux-kernel -- all over the place...
At that point, I was getting too many to keep up with ... so I stopped
searching...
$[] has is -- I would bet, Universally, used MORE than $(())...
I believe you'd lose, but it's
Maarten Billemont wrote:
Any particular reason for not removing old undocumented functionality,
or is that mostly the nature of this beast - dragging along and maintaining
ancient code for the sake of compatibility?
So 'yesturday' is "ancient" for you?... that's really means somet
Maarten Billemont wrote:
On 08 Apr 2012, at 21:30, Chet Ramey wrote:
On 4/8/12 3:02 PM, Maarten Billemont wrote:
Any particular reason for not removing old undocumented functionality, or is
that mostly the nature of this beast - dragging along and maintaining ancient
code for the sake of
Mike Frysinger wrote:
On Saturday 07 April 2012 16:45:55 Linda Walsh wrote:
Is it an accidental omission from the bash manpage?
it's in the man page. read the "Arithmetic Expansion" section.
-mike
My 4.2 manpage says:
Arithmetic Expansion
Arithmetic e
In modifying some released code on my distro,I ran into the
extensive use
of $[arith] as a means for returning arithmetic evaluations of the
expression.
I vaguely remember something like that from years ago, but never see any
reference to
it -- yet it works, and old code seems to r
Elliott Forney wrote:
I wish bash would happily execute lines that begin with a semicolon,
i.e., treat it as a no-op followed by a command. The following
examples come to mind:
$ infloop& echo hello
hello
$ infloop&; echo hello
bash: syntax error near unexpected token `;'
$ echo hello; ec
Greg Wooledge wrote:
On Wed, Apr 04, 2012 at 04:08:04PM -0700, Linda Walsh wrote:
function ll { ... }
Just for the record, a one-line function definition requires a ; before
the closing curly brace.
ll() { ls -l "$@";}
---
Can you say 'irrelevant detail'
mhenn wrote:
Am 24.06.2011 11:51, schrieb Harald Dunkel:
Hi folks,
A colleague pointed me to this problem: If I run
( set -e; ( false; echo x ) )
in bash 4.1.5, then there is no screen output, as
expected. If I change this to
( set -e; ( false; echo x ) || echo y )
then I get
jrrand...@gmail.com wrote:
function expand_alias() # expand an alias to full command
{
if [ "$1" = "." ]; then
argument="\\$1"
else
argument="$1"
fi
match=$( alias -p | grep -w "alias $argument=" )
if [ -n "$match" ]; then
expanded="`
:34:21 -0800
From: Linda Walsh
To: bug-bash
I have several files that ***source*** the ***lib*** files*** by expecting
the name of the lib to be checked against PATH --
How look up [lib] files
relative to PATH regardless of them having a '/' in them?
---
You are welcome!
N
John Kearney wrote: ...
[large repetitive included text elided...]
why not just do something like this?
<26 line suggested 'header' elided...>
gives you more control anyway, pretty quick and simple.
At least 30% of the point of this is to take large amounts
of common initializatio
Greg Wooledge wrote:
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
Greg Wooledge wrote:
Any pathname that contains a / should not be subject to PATH searching.
You are alone in this opinion -- as most application don't follow that rule.
??
Eric Blake wrote:
On 02/29/2012 12:26 PM, Linda Walsh wrote:
Any pathname that contains a / should not be subject to PATH searching.
Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
execlp(2) and friends.
Is it that you don't read english as a first languag
Greg Wooledge wrote:
On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
How can one get the same behavior as before and look up files
relative to PATH regardless of them having a '/' in them?
What? That sounds like it WAS a bug before, and you had somehow
interpret
I have several files that source the lib files by expecting
the name of the lib to be checked against PATH --
but this no longer works when the library is in lib/filename.
How can one get the same behavior as before and look up files
relative to PATH regardless of them having a '/' in them?
Why
Eric Blake wrote:
Don't think of it as 'wide-int', rather, think of it as 'the integral
type that both contains wchar_t and WEOF'. You cannot write 'signed
wint_t' nor 'unsigned 'wint_t'.
---
?? You say don't think of it that way, but unless I missed something,
just like wchar stood for '
Eric Blake wrote:
On 02/22/2012 05:19 AM, Linda Walsh wrote:
Eric Blake wrote:
Not only can wchar_t can be either signed or unsigned, you also have to
worry about platforms where it is only 16 bits, such as cygwin; on the
other hand, wint_t is always 32 bits, but you still have the issue
Eric Blake wrote:
Not only can wchar_t can be either signed or unsigned, you also have to
worry about platforms where it is only 16 bits, such as cygwin; on the
other hand, wint_t is always 32 bits, but you still have the issue that
it can be either signed or unsigned.
What platform uses
Chet Ramey wrote:
On 2/8/12 9:28 PM, Linda Walsh wrote:
Please note, I didn't compare anyone or their actions to those of Nazi's,
This discussion has gone on for a long time; the probability of a
comparison involving Nazis hit 1; ipso facto, Godwin's Law holds.
Bu
ke fashion, THOUGH, if we wanted to compare and look at those who are
engaged in dictatorial actions, and those who are more commonly marginalized as
outsiders, I'm sure such a comparison would be 'pointless' (though ironic).
Chet Ramey wrote:
On 2/8/12 6:31 PM, Linda Walsh wrot
Eric Blake wrote:
On 01/30/2012 02:27 PM, Linda Walsh wrote:
Chet Ramey wrote:
As Eric said, the other parts of the Posix description make it clear that
the `ignoring set -e' status is inherited by subshells.
The original POSIX standard made this clear -- in that
it was o
Chet Ramey wrote:
As Eric said, the other parts of the Posix description make it clear that
the `ignoring set -e' status is inherited by subshells.
The original POSIX standard made this clear -- in that
it was only a failure of a 'simple' command that resulted' in
an err-exit'.
It seems there is a a platform dependent bug somewhere:
> HISTSIZE=$(((3**15))
echo $HISTSIZE
1000
--- but you have no history...
Pierre Gaston wrote:
Setting HISTFILESIZE to 2147483647 gives you 68 years of history at
one command per seconds
(I hope I got my math right)
with say
DJ Mills wrote:
OK. �How about if that sentence began with `When specifying n, the
digits greater ...'?
declare -i foo; foo=20#a2; echo "$foo"
202
[base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number.
---
Slightly more exact/pedantic, how about:
Syntax for integer cons
DJ Mills wrote:
OK. �How about if that sentence began with `When specifying n, the
digits greater ...'?
declare -i foo; foo=20#a2; echo "$foo"
202
[base#]n, 'base' is a INTEGER 2-64, then '#', followed by the number.
^^^ That's much more clear!
Andreas Schwab wrote:
Linda Walsh writes:
var=0a32; echo $var
-bash: 0a32: value too great for base (error token is "0a32")
Which part of "Constants with a leading 0 are interpreted as octal
numbers" did you not understand?
The part that said the ones that
reading the section no constants:
Constants with a leading 0 are interpreted as octal numbers. A
leading
0x or 0X denotes hexadecimal. Otherwise, numbers take
the form
[base#]n, where base is a decimal number between 2 and 64
representing
the arithmetic base,
Chet Ramey wrote:
On 1/14/12 12:49 AM, Linda Walsh wrote:
/* vim: ts=1 sw=1 et sc fo=cqwa1 tw=78 syntax=css */
There's actually 1 parts 2 this, I ran into the 2nd while testing the
first...
Like Greg Wooledge, I wasn't able to reproduce the second issue with
`read -N 1
/* vim: ts=1 sw=1 et sc fo=cqwa1 tw=78 syntax=css */
There's actually 1 parts 2 this, I ran into the 2nd while testing the
first...
I wanted to be able to check the keyboard if the user had 'typed' ahead,
and mean to answer an upcoming question on purpose or if it was left
over from a previou
Clark J. Wang wrote:
On Fri, Jan 6, 2012 at 00:33, Peng Yu wrote:
But beware to clearly document these by giving working
EXAMPLE code which include these three commands (not just text
explanation without working code, by "working code" I mean code
snippet is discouraged, a complete completio
Chet Ramey wrote:
On 9/27/11 6:41 PM, Roger wrote:
Correct. After reading the entire Bash Manual page, I didn't see much mention
of documentation resources (of ERE) besides maybe something about egrep from
Bash's Manual Page or elsewhere on the web. After extensive research for
regex/regex
At the # prompt, if I type:
#
Thomas De Contes wrote:
Le 25 août 2011 à 14:36, Greg Wooledge a écrit :
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't
` Greg Wooledge wrote:
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
RFC 2822 (section 2.2) says
Chet Ramey wrote:
In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
That's not valid UTF-8, since UTF-8 requires that the shortest sequence
be used to encode a character.
This is exactly true...
Valid UTF-8 is anythi
Greg Wooledge wrote:
On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:
> Ken Irving wrote:
>> Maybe this? today_snaps=( ${snap_prefix} )
> but as you mention, that will put them into an arraysorry
> "imprecise terminology" list for me is some n
` Greg Wooledge wrote:
Now that one is suprising, as it's supposed to take the output of
the ... hmmm.yup!... that's exactly what it does.
takes the work and executes it and returns the results on stdin as
a single quoted blob of output:
> read a <<< *.txt
> echo $a
apc_c
` Chet Ramey wrote:
On 8/18/11 9:37 AM, Greg Wooledge wrote:
The word following the redirection operator in the following descrip-
tions, unless otherwise noted, is subjected to brace expansion, tilde
expansion, parameter expansion, command substitution, arithmetic expan???
` Greg Wooledge wrote:
On Thu, Aug 18, 2011 at 08:03:41AM -0700, Linda Walsh wrote:
4.2 introduce a new -g to declare a global variable inside a function.
Which doesn't say what it would do in situations like the above.
Then let's test:
imadev:~$ echo $BA
Pierre Gaston wrote:
l understood a while ago, now I'll just stop feeding the troll.
---
You obviously feel there needs to be a right and wrong, and
if you haven't made me wrong, you've lost -- indicated by
your resorting to name calling rather than discussing issues.
Sigh.
` Greg Wooledge wrote:
On Thu, Aug 18, 2011 at 06:02:14AM -0700, Linda Walsh wrote:
The "shopt -s expand_aliases" feature has been in bash since I first
encountered it in ~1999.
Fine. You know more bash bad practices than I do. You win.
Just because you didn'
Pierre Gaston wrote:
Is this a question? or are you trying to make a point?
It is both -- a chance to find answer to a question, or make
the point that aliases in scripts have a useful purposes that
can't be replaced by function clls.
For the question (If I understand correctly):
1) Most
Pierre Gaston wrote:
On Mon, Aug 15, 2011 at 2:31 AM, Linda Walsh wrote:
Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
Pierre Gaston wrote:
Linda:
please show quote the section
that shows using an variable that holds the name of an array to be used (and
Greg Wooledge wrote:
[[[ yeah, am running a bit behind]...
On Mon, Aug 15, 2011 at 12:45:58AM -0700, Linda Walsh wrote:
> #!/bin/bash -exu
> +[shopt -s expand_aliases extglob]
>
> alias sub=function
> alias unless='if !'
Aliases don't even *work* in s
` Eric Blake wrote:
On 08/15/2011 04:40 PM, Sam Steingold wrote:
* Andreas Schwab [2011-08-15 22:04:04 +0200]:
Sam Steingold writes:
Cool. Now, what does this imply?
"For almost every purpose, shell functions are preferred over
aliases."
so, how do I write
alias a=b
as a function?
(
Ken Irving wrote:
On Mon, Aug 15, 2011 at 08:19:01PM -0700, Linda Walsh wrote:
today_snaps="$('ls' -1 ${snap_prefix} 2>/dev/null |tr "\n" " " )"
This one is so bad, I saved it for last. Ack! Pt! Wait, what? Why? What
the? Huh?
Dennis Williamson wrote:
On Mon, Aug 15, 2011 at 10:19 PM, Linda Walsh wrote:
How do I determine the location of my script?
http://mywiki.wooledge.org/BashFAQ/028
??? I don't understand the need for complexity -- what I have works. Its a
few
lines@ most -- I use the sa
` Dennis Williamson wrote:
Also, it's usually not necessary to maintain an index variable
and use shift in a while loop. Use "for arg; do" which uses an implied
$@.
I tried to implement your suggestion and quickly ran into the reasons
why I did what I did.
Using the 'for x;
` Dennis Williamson wrote:
On
Greg already covered some important points and I'll add a few more.
*cough*
sorry, I just haven't responded ... I threw up my hands in disgust
and got too
irritated to respond, so have done other things.
As has been said before, d
` Linda Walsh wrote:
The latest error I got is a a simple type -- most of them probably
are, with that many
lines of code in ~3-4 weeks, there's bound to be -- trouble is I'm
stubborn sometimes
about 'punishing myself'' when I mess up...which isn't alway
` Dennis Williamson wrote:
http://mywiki.wooledge.org/XyProblem
I suspect that you are hung up on the way to do something and have
lost sight of (or failed to tell us) what it is you're *actually*
trying to do.
If what you're trying to do requires complex data structures, you're
either doing
` Dennis Williamson wrote:
On Sun, Aug 14, 2011 at 6:31 PM, Linda Walsh wrote:
please show quote the section
that shows using an variable that holds the name of an array to be used
(and assigned to)
The FAQ covers indirect,
it covers arrays,
but I see no place where it covers
Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
Pierre Gaston wrote:
Linda:
please show quote the section
that shows using an variable that holds the name of an array to be used
(and assigned to) else ...
The proof is in the faq, you could have found it if you were n
` Pierre Gaston wrote:
On Sun, Aug 14, 2011 at 7:51 AM, Linda Walsh wrote:
Dennis Williamson wrote:
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
I have to use 'indirect' syntax: � � ${!name}
But that doesn't seem to play well with array syn
` Michael Witten wrote:
On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid,
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid, but you'll probably have to
construct and then eval the right code by hand:
$(eval
` Dennis Williamson wrote:
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
I have to use 'indirect' syntax: ${!name}
But that doesn't seem to play well with array syntax:
${#${!name}[*]}# bash: ${#${!name}[*]}: bad substitution
What syntax would
I want to have an array of 'names'.
given a name, "X", I had a prefix, _p_, so have _p_X,
I want to access / manipulate it as an array.
so given I pass in a name in a var, I have to use 'indirect' syntax:
${!name}
But that doesn't seem to play well with array syntax:
${#${!name}[*]}
bash:
Seems like this a bug in how 'groff' is configured to display various
characters.
Sorry the waste of space.
Linda Walsh wrote:
In my bash package:
rpm -qi bash
Name : bash Relocations: (not relocatable)
Version : 4.1 Vendor: openSUSE
Release : 20.25.1 Build Date: Sun 27 Feb
Greg Wooledge wrote:
On Fri, Aug 12, 2011 at 12:19:59PM -0700, Linda Walsh wrote:
Under -e, it would fail on the 'let' statement
This is one of the cases I mention on http://mywiki.wooledge.org/BashFAQ/105
AND there, you explain WHY this needs to be fixed.
In my bash package:
rpm -qi bash
Name : bash Relocations: (not relocatable)
Version : 4.1 Vendor: openSUSE
Release : 20.25.1 Build Date: Sun 27 Feb 2011 05:51:30 AM PST
Install Date: Sun 22 May 2011 01:28:49 PM PDT Build Host: build31
...
in the 'bash' manpage, under the 'set' option, under
Greg Wooledge wrote:
On Fri, Aug 12, 2011 at 08:18:42AM -0700, Linda Walsh wrote:
> If I write a==0 on the bash command line, it will generate an error.
>
> a=0 does not. 'Bash' knows the difference between an assignment and
> a equality test in math.
imadev:~$ ((a
Greg Wooledge wrote:
On Thu, Aug 11, 2011 at 11:56:10PM -0700, Linda Walsh wrote:
**Exception**
declare -i a
a=0
--
As a is declared to be an integer, it has the results evaluated
at assignment time. a=0 is an integer expression that doesn't set
$?=1
Neither should:
((a=0))
a
Eric Blake wrote:
On 08/10/2011 10:39 PM, Linda Walsh wrote:
"It sounded to me like $(( )) would be translated into "$( () )",
turning off arithmetic expansion. Did I read that ___incorrectly__?
Yes, you read it incorrectly.
---
*thankyou*
POSIX is saying that _
` Stephane CHAZELAS wrote:
2011-08-08, 13:55(-07), Linda Walsh:
[...]
and both 'exit' and 'return' should return error "ERANGE" if "--posix" is
set, and -1 is given. Iinvalid option doesn't make as much sense, in
this situtation, if it was -
Chet Ramey wrote:
> If not, then wouldn't
> $((( ))) be turned into $( (( )) ), meaning the arith returns a
> status,
> and not the calculation. (I've tested this, and this is the case.
This is demonstrably false.
---
No... you've only proven that you should have a bit of 'compassion'
for
Chet Ramey wrote:
Is this a fluke, due to the above changes NOT being 4.1? Or is
this construction going to break in 4.2:
'$((( )))'
What does `break' mean? It's already written in a manner more
confusing and obscure than necessary. What value do you think the
extra set of p
Eric Blake wrote:
On 08/10/2011 03:59 PM, Linda Walsh wrote:
Is this a fluke, due to the above changes NOT being 4.1? Or is this
construction going to break in 4.2:
'$((( )))'
According to POSIX, this construction should be parsed as an arithmetic
substitution $(()) where the exp
Chet Ramey wrote:
Yes. It's a case of not saving and restoring enough state across
possibly-
recursive calls to the shell parser. (The assignment statement is the
key
in this case.)
> So, I compared subst.c files from bash-4.1-9 and bash-4.2-10 and was
> able
> to build a patch that it
This may be some 'cockpit error', but this is what I'm seeing right
now and AFAICT, bash is broken.
I have this statement:
next line is line #300
have_dep -v base_mp_diff base_vg osnap_lv osnap_vg && {
nextents="$(get_nextents_for_space_on_vg_w_minfree \
Chet Ramey wrote:
On 8/9/11 8:10 PM, Linda Walsh wrote:
The change to make (( honor the `errexit' option came in with bash-4.1,
part of the cleanup after the Posix changes to the specification of the
behavior of `set -e'. Most of the other changes in this area came in
wit
Chet Ramey wrote:
On 8/9/11 8:19 PM, Linda Walsh wrote:
Linda Walsh wrote:
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained utils should see 'eof', and
should then flush their output...at least that was my belief
Bob Proulx wrote:
Chet Ramey wrote:
Linda Walsh wrote:
Ideas?
You're probably running into grep (and sort, and sed) buffering its
output. I haven't been able to figure out a way past that.
This may be a good point to mention this reference:
http://www.pixelbeat.org/p
Chet Ramey wrote:!
It's not attempting command completion, since it doesn't think
it's in a context where a command name is expected (the completion
line parsing is pretty ad-hoc -- it doesn't use the shell parser). It's
attempting readline's default filename completion. I'll have to see
whethe
Linda Walsh wrote:
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained utils should see 'eof', and
should then flush their output...at least that was my belief in how they
"should" be working...(sigh)...
-
Chet Ramey wrote:
What am I doing wrong?
You're probably running into grep (and sort, and sed) buffering its
output. I haven't been able to figure out a way past that.
Chet
---
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained ut
Chet Ramey wrote:
On 8/8/11 11:43 PM, Linda Walsh wrote:
I have a function that returns true/false.
during development, (and sometimes thereafter depending on the script, I
run with -eu, to make sure the script stops as soon as there is a
problem (well, to 'try' to make sure, many
I have a function that returns true/false.
during development, (and sometimes thereafter depending on the script, I
run with -eu, to make sure the script stops as soon as there is a
problem (well, to 'try' to make sure, many are caught.
But there are two instances that cause an error exit that s
Michael Witten wrote:
Reasonable? Or is someone going to tell me why blather is a
desired and wanted feature (under one standard or another! ;-))...
Reasonable, but naive.
Interactive bash can complete variable names, even when they are quoted.
---
That's cool!
I'm talking about a
Roger wrote:
On Mon, Aug 08, 2011 at 02:28:00PM -0700, Linda Walsh wrote:
Lest some think functions can replace aliases, there's a line in the manpage
that I feel needs amending. Currently it says:
"For almost every purpose, aliases are superseded by shell functions."
Whi
Chet Ramey wrote:
Sure. It's just removing the three lines of code that were added
between bash-3.2 and bash-4.0. The question was always whether that's
the right thing to do, and whether the result will behave as Posix
requires.
That explains why I never ran into this before!
Michael Witten wrote:
In any case, even if `no_empty_cmd_completion' were to behave as Linda
expected, her tabs would still get eaten when pasted on the interactive
command line.
---
Which is what Linda expects...
the function definition wouldn't hold spaces or tabs or whitespace unle
Lest some think functions can replace aliases, there's a line in the manpage
that I feel needs amending. Currently it says:
"For almost every purpose, aliases are superseded by shell functions."
While true, it may too likely be read by some to mean that aliases have no
useful purpose. So I'
Bob Proulx wrote:
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 abo
Eric Blake wrote:
(exit -1); return
That's not portable, either. exit is allowed to reject -1 as invalid.
POSIX is clear that exit and return have the same constraints - if an
argument is provided, it must be 0-255 to be portable.
However, you are on to something - since bash allows 'exi
Davide Brini wrote:
foo() { # hit enter here
# hit tab here
Display all 112 possibilities? (y or n)
The latter only attemps completion from names in the current directory.
---
Right. That was my issue.
My understanding is it shouldn't try to perform completion on an empty
line.
Michael Witten wrote:
On Mon, Aug 8, 2011 at 18:44, Linda Walsh wrote:
I was testing functions in my shell, I would cut/paste,
thing is, with each past, I'd get my dir listed (sometimes multiple times)
on each line entered.
Now I have:
shopt:
no_empty_cmd_completion on
i.e. it&
I was testing functions in my shell, I would cut/paste,
thing is, with each past, I'd get my dir listed (sometimes multiple times)
on each line entered.
Now I have:
shopt:
no_empty_cmd_completion on
i.e. it's not supposed to expand an empty line
but type in
function foo {
return 1
}
When
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 sta
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 &#x
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
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 arra
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
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).
Bob Proulx wrote:
Eric Blake wrote:
Linda Walsh wrote:
I guess I don't use negative return codes that often in shell,
I guess I don't use negative return codes that often in shell, but
I use them as exit codes reasonably often.
'return' barfs on "return -1"...
Since return is defined to take no options, and ONLY an integer,
as the return code, it shouldn't be hard to fix.
Seem to fail on any negative number
a make -j will automatically try to schedule tasks on different cpu's if
they are needed.
Perhaps your job's weren't sufficiently long, or you didn't specify the
makefile to be
done in parallel.
but try this:
for i in {0..7};do
(for ((j=0;j<10**6;++j)) {a=$j})&
done
That will run 8 loops of a
401 - 500 of 611 matches
Mail list logo
