On 18.08.2011 12:44, Stephane CHAZELAS wrote:
2011-08-17, 08:24(-04), Greg Wooledge:
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
term
2011-10-3, 09:12(-04), Greg Wooledge:
> On Mon, Oct 03, 2011 at 12:56:43PM +, Stephane CHAZELAS wrote:
>> If zsh is not compatible with any other shell, then bash isn't
>> either. What do you mean?
>
> http://zsh.sourceforge.net/FAQ/zshfaq02.html#l10
>
> "because of all the options it is not sa
On Mon, Oct 03, 2011 at 12:56:43PM +, Stephane CHAZELAS wrote:
> If zsh is not compatible with any other shell, then bash isn't
> either. What do you mean?
http://zsh.sourceforge.net/FAQ/zshfaq02.html#l10
"because of all the options it is not safe to assume a general zsh run
by a user will be
2011-10-3, 08:36(-04), Greg Wooledge:
> On Thu, Aug 18, 2011 at 11:10:17AM +0100, Stephane CHAZELAS wrote:
>> >> Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
>> > "no force in the universe can put NUL bytes into shell strings usefully"
>
>> No, zsh supports NUL bytes in its strin
On Thu, Aug 18, 2011 at 11:10:17AM +0100, Stephane CHAZELAS wrote:
> >> Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
> > "no force in the universe can put NUL bytes into shell strings usefully"
> No, zsh supports NUL bytes in its strings happily. It's even in
> the default $IFS.
2011-08-17, 08:24(-04), Greg Wooledge:
> 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
2011-08-14, 02:43(+00), Michael Witten:
[...]
>> Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
>
> "no force in the universe can put NUL bytes into shell strings usefully"
>
> Ain't that the goddamn Truth!
No, zsh supports NUL bytes in its strings happily. It's even in
the defaul
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 number of objects
> in a s
> On Thu, Aug 18, 2011 at 02:42:03PM -0400, Chet Ramey wrote:
> > The expansions are the default set as described in the quoted paragraph,
> > without pathname expansion and, since the result is passed to the command
> > as a single string, word splitting.
> >
> > I think the confusion arises over
On Thu, Aug 18, 2011 at 02:42:03PM -0400, Chet Ramey wrote:
> The expansions are the default set as described in the quoted paragraph,
> without pathname expansion and, since the result is passed to the command
> as a single string, word splitting.
>
> I think the confusion arises over the precise
On 8/18/11 12:14 PM, Greg Wooledge wrote:
> On Thu, Aug 18, 2011 at 10:55:11AM -0400, Chet Ramey wrote:
>> The quoted paragraph applies to all redirection operators (and parameter
>> and variable expansion are still identical). The description of <<<
>> notes that it does not perform pathname expa
On Thu, Aug 18, 2011 at 10:13:45AM -0700, Linda Walsh wrote:
>Um...the description from "<<<", above indicates it is...subject
> to pathname expansion...If I had matching filesin my dir, it
> expanded and returned them,
> so I'm pretty sure it does PN expansion.
As noted, you're being fooled
` 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???
On Thu, Aug 18, 2011 at 09:26:42AM -0700, Linda Walsh wrote:
> It's like "-e" was very using in bash 3.0-4.0, but you didn't know it so
> thought it worthless.
I certainly knew about -e. It was bad back then, too. It's arguably
worse now, because there are even more variants in implementation th
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't know about it do
On Thu, Aug 18, 2011 at 10:55:11AM -0400, Chet Ramey wrote:
> The quoted paragraph applies to all redirection operators (and parameter
> and variable expansion are still identical). The description of <<<
> notes that it does not perform pathname expansion at all.
The word following the red
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???
>>sion, quote rem
On 8/18/11 9:02 AM, Linda Walsh 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‐
>sion, quote removal, pa
On Thu, Aug 18, 2011 at 5:13 PM, Linda Walsh wrote:
>
>
>
> 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 sect
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
assigned
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.
> > b="one two three"
> > read a <<<$b
> > echo $a
> one two three
>The
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 scripts.
Hopefully you someon
On Tue, Aug 16, 2011 at 02:11:43PM -0700, Linda Walsh wrote:
> 2) His knowledge base about bash seems to be dated or lacking.
> His page on indirect assignment skips using arith expressions and skipped
> one line assignments for assigning to indirect vars using the "<<<"
It's a wiki, you know. I
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 number of objects in a string
> separated by so
On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:
> Ken Irving wrote:
> >It seems to me that there are real bugs in applying set -e that can only
> >be fixed by handling more special cases in the bash code,and those cases
> >may vary for different scripts.
>
> >[snip]
> >set ...
> >
On Tue, Aug 16, 2011 at 4:11 PM, Linda Walsh wrote:
>
>
>
> Dennis Williamson wrote:
>>
>
> Who's Greg? I mean before some days ago and other than seeing the name on
> this list, who is he from Adam that someone should think his FAQ is
> important?
> I don't know the name other than from s
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?
...
What would you do to search for fil
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 same in per
On Tue, Aug 16, 2011 at 11:45 AM, Ken Irving wrote:
>
> I'm guessing the 'Ack!' was maybe for 'useless use of subshell'?
>
>
No, it was for the ls.
--
Visit serverfault.com to get your system administration questions answered.
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?
> ...
> What would you do to search for files w/wild cards and return th
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 same in perl. has worked for
On Mon, Aug 15, 2011 at 08:19:01PM -0700, Linda Walsh wrote:
> ` Dennis Williamson wrote:
> >As has been said before, don't use "bash -e".
>Why don't you convince Chet to remove it then?
He can't, because people like you keep using it. Also, it's probably
mandated by POSIX. I can't be bothe
` 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
On Mon, Aug 15, 2011 at 2:45 AM, Linda Walsh wrote:
>
>
>
> ` 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''
On Mon, Aug 15, 2011 at 12:45:58AM -0700, Linda Walsh wrote:
> #!/bin/bash -exu
> alias sub=function
> alias unless='if !'
Aliases don't even *work* in scripts.
> typeset -xr sub unless
>
> declare -a SAVE_ARGS=( "$@" )
> typeset -xr snapdir='snapdir'
>
> # in shell: white is black and black i
` 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 always
productive! ;-)
Sometimes typo's
` 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
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 it wrong in Bash or Bash is the
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 assigned to)
` 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 t
On Sun, Aug 14, 2011 at 6:31 PM, 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 assigned to)
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
On Sun, Aug 14, 2011 at 10:39 PM, Linda Walsh wrote:
>
>
>
> ` 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: �
` 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 syntax:
${#${!name}[*]} � �# �
` 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, but you'll pro
On Sun, Aug 14, 2011 at 05:56, 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 prob
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, but you'll probably have to
>> cons
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 syntax:
>>> ${#${!name}[*]} # bash: ${#${
` 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 "echo \${#$name[*]}")
` 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 use for this?
Please
On Sun, Aug 14, 2011 at 00:49, Dennis Williamson
wrote:
> On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
>>
>>
>>
>> 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 na
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
>
>
>
> 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 t
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 "echo \${#$name[*]}")
thx for the answer. I didn't realize my error, that white space defines the
separation of words, even when dealing with symbols. wish vim syntax
highlighted this stuff as the shell interprets because it sees it as a
comment. anyways like I said thanks for the explanation. I'm not going to
forget t
"Caleb Cushing" <[EMAIL PROTECTED]> wrote:
> the line
> FEATURES="parallel-fetch ccache distlocks"# userfetch userpriv usersandbox
>
> I was told my bug is not a bug because there was no space in between the "#
>
> putting a space does fix the problem but I can't recall that I've ever seen
> any do
58 matches
Mail list logo
