Re: Syntax Question...
` 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 probably have to
construct and then eval the right code by hand:
$(eval "echo \${#$name[*]}")
bingo. (sigh)
I refactored and am essentially using spaces to store the values in
a string, then when I want to check the, I throw them into an array and
manip.
e.g. (not showing all supporting code)
declare -axr _plst_t='_plist_'
declare -axl defined_PLists=()
add things to the list...
plist="$_plst_t$plist"
local -al plist_deps=( $plist )
{search for value in list, ...]
unless ((found)) ; then
plist_deps[${#plist_deps[*]}]="$subdep"
eval "$plist=( "$plist_deps[@]" )"
fi
You want this:
unless ((found)) ; then
plist_deps+=("$subdep")
eval $plist='("${plist_deps[@]}")'
fi
Of course, isn't the variable `plist' supposed to be a reference to
your *string* variable that holds a space-separated list of items? In
that case, the last line should be:
IFS=' ' eval $plist='"${a[*]}"'
---
Damn your good...! Thanks... (saw your other email as well...well
fix the syntax
my eyes are glazing over...from this script...)
Fortunately just started writing that section of code this afternoon and
haven't put it in to use yet...
Just now developing a @list=dep dep dep,
to have a meta-list syntax for dependencies ...
Still checking as singles...
...but every once in a while
I need a good 'idiosyncratic', assembly-language -like challenge...
almost 1500 lines, not counting externally called support scripts --
though over 1000
of those are in 'library code'
Re: Syntax Question...
` 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}[*]} � �# �bash: ${#${!name}[*]}: bad substitution
What syntax would I use for this?
Please read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
I looked at the pageread every section that was >basic & some basic...
nothing about using indirect variables with arrays... (let alone assigning
to them)..
lies
Is this an anime?'Lies! All lies!..' Such lines are
usually said by the bad buy and are made clearly evident to others
that such is said, not because it is true, but because the person
is in denial of the truth or wishes to convince others that it is
not true.
But, usually (depends on how dark the anime is (or, how much, it
is like real life ;~/ ) ) the truth comes out.
But in any event, should I be gullible and ask for proof, or should I
simply take it as humor? If the former, please show quote the section
that shows using an variable that holds the name of an array to be used
(and assigned to) else, ... I love the French...though I admit to
an often low grasp of French colloquialisms and generally (in English)
less than 100% detection of subtle humor -- that percentage falls as
language and cultural differences rise.
But (I'm so damn unfun/lame sometimes), if you don't respond, I'll
assume you believed it not worth it as was supposed to be humorous, and
having to explain such, crimps the humorist's style... (I do have a sense
of humor -- just not always the same as some other's..).
Linda
Re: Syntax Question...
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: � � ${!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 read BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
>>>
>>> I looked at the pageread every section that was >basic & some
>>> basic...
>>>
>>> nothing about using indirect variables with arrays... (let alone
>>> assigning
>>> to them)..
>>>
>>
>> lies
>>
>
>
> Is this an anime? 'Lies! All lies!..' Such lines are
> usually said by the bad buy and are made clearly evident to others
> that such is said, not because it is true, but because the person
> is in denial of the truth or wishes to convince others that it is
> not true.
>
> But, usually (depends on how dark the anime is (or, how much, it
> is like real life ;~/ ) ) the truth comes out.
>
> But in any event, should I be gullible and ask for proof, or should I
> simply take it as humor? If the former, please show quote the section
> that shows using an variable that holds the name of an array to be used
> (and assigned to) else, ... I love the French...though I admit to
> an often low grasp of French colloquialisms and generally (in English)
> less than 100% detection of subtle humor -- that percentage falls as
> language and cultural differences rise.
>
> But (I'm so damn unfun/lame sometimes), if you don't respond, I'll
> assume you believed it not worth it as was supposed to be humorous, and
> having to explain such, crimps the humorist's style... (I do have a sense
> of humor -- just not always the same as some other's..).
> Linda
>
The proof is in the faq, you could have found it if you were not busy
trolling the list.
Re: Syntax Question...
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 not busy trolling the list. Guess this was not possible. The FAQ covers indirect, it covers arrays, but I see no place where it covers the combination. If you see such, then quote it. Don't just wave your arms around making unsubstantiated claims or accusations. I didn't ask for the impossible -- just a quote. Apparently that was too much to ask for, so you call me a trollya, right. Who's the troll?
Re: Syntax Question...
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) else ... >>> >> >> The proof is in the faq, you could have found it if you were not busy >> trolling the list. >> >> > > > Guess this was not possible. > The FAQ covers indirect, > it covers arrays, > but I see no place where it covers the combination. > If you see such, then quote it. Don't just wave your arms around > making unsubstantiated claims or accusations. > > I didn't ask for the impossible -- just a quote. > > Apparently that was too much to ask for, so you call me a trollya, > right. > Who's the troll? > > > > > > In short, it says "don't do that." To elaborate, if you need complex data structures, use a language that supports them. Python for example. A selection of the relevant passages: Obligatory Note Putting variable names or any other bash syntax inside parameters is generally a bad idea. It violates the separation between code and data, and as such puts you on a slippery slope toward bugs, security issues, etc. Even when you know you "got it right", because you "know and understand exactly what you're doing", bugs happen to all of us and it pays to respect separation practices to minimize the extent of damage they can cause. Aside from that, it also makes your code non-obvious and non-transparent. Normally, in bash scripting, you won't need indirect references at all. Generally, people look at this for a solution when they don't understand or know about Bash Arrays or haven't fully considered other Bash features such as functions. . . . This is the kind of approach we'd expect in a high-level language, where we can store hierarchical information in advanced data structures. The difficulty here is that we really want each element of the associative array to be a list or another array of command strings. But the shell simply doesn't permit that kind of data structure. So, often it pays to step back and think in terms of shells rather than other programming languages. Aren't we just running a script on a remote host? Then why don't we just store the configuration sets as scripts? Then it's simple . . . If you need an associative array but your shell doesn't support them, please consider using AWK instead. . . . Bash can almost do it -- some indirect array tricks work, and others do not, and we do not know whether the syntax involved will remain stable in future releases. So, consider this a use at your own risk hack. . . . The bad news is that if you fail to sanitize the right hand side correctly, you have a massive security hole. Use eval at your own risk. Please try to be briefer and more on topic in your posts to this list, by the way. -- Visit serverfault.com to get your system administration questions answered.
Re: Syntax Question...
` 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 the combination. That's EXACTLY what I said -- it doesn't show anyway to do it, in fact, it points the the exact problem I've been complaining about is bash's instability in it's extended features. I thought it would be like perl -- stable progression, not random jumps that break code. All he's saying is bash "shouldn't" or "can't (with any stability), but used for anything complex. He may be right. Personally I think it sucks. I was very happy with bash's extensions, and their progression -- right up to this last revision, when functionality was removed, and others functionality was broken -- I USE tabs when typing a program into bash -- not all the time, but now I can't -- in "single quotes", it tries to expand to all the words in my curdir. The script I've been working on was suppose to be relatively simple -- but given the all the error checking I've been putting in, and all of the state tracking so a run of the script wouldn't come in and corrupt what had been left by a previous run, it's gotten ALOT more complex. Conceptually...about 8-10 lines of english, -> almost 1500 lines of bash code -- MUCH of which is to compensate for bashes new broken features. One can claim it's my fault for not using POSIX, but I don't have this problem in perl (the python people did...) maybe I haven't appreciated how stable perl has been -- like C. But 1) create snapshot 2) look for oldest active snapshot 3) rsync the diffs from the oldest snapshot compared against current to a 'diff vol' 4) create new 'static vol' sized to content on diff vol, and get rid of the oldest active snapshot. That's. IT! But... .9) see if we have already created a snapshot today and require an override flag 3.5) label diff vol with content label of snapshot this came from. with labeled diff vol, can remove old active snapshot (which needs to be removed before creating a new one w/same name & same mount point, but static)... (could create new vol, and do renames, but would result in >lvm fragmentation). 2.8) before copying to diff dir -- make sure it is the correct mounted file system and delete it's contents (dependent on there being a "valid snap copy"...) which doesn't get set until the diff dir is copied to the new static stap and IT gets a label -- saying that the diff-copy completed successfully. etc. etc. etc... It's just been growing... (I didn't come close to listing all the checks that are in there now)... So conceptually --- looked like a simple shell script. but...to handle bash's broken error handling, all steps have to be 'interlocked' -- state 'checked' into a file system, and validated before going to the next step. Otherwise, I end up with more problems than you want to know about. Please try to be briefer and more on topic in your posts to this list, by the way. I'm stopping now. Maybe not entirely on-topic, but I wasn't the one who started a side conversation by claiming that the information I needed was on URLxxyz...when it wasn't. It wasn't obvious from anyone that there was some subtle hint that trying to use bash for things like this was ridiculous (if that's the message I was supposed to get from reading it).I may be tending more to to agreebut I honestly thought bash seemed forwardly stablewith broken compat, being relegated to --posix mode. I'm slow to change when things 'break' -- I'd prefer to try to get them fixed, or fix them, than move-on. I know -- most people just move on...whatever. Thanks for the clarification (I think?)...
Re: Syntax Question...
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) else ...
>>>
>>
>> The proof is in the faq, you could have found it if you were not busy
>> trolling the list.
>>
>>
>
>
> Guess this was not possible.
> The FAQ covers indirect,
> it covers arrays,
> but I see no place where it covers the combination.
> If you see such, then quote it. Don't just wave your arms around
> making unsubstantiated claims or accusations.
>
> I didn't ask for the impossible -- just a quote.
>
> Apparently that was too much to ask for, so you call me a trollya,
> right.
> Who's the troll?
>
# Bash -- trick #1. Seems to work in bash 2 and up.
realarray=(...) ref=realarray; index=2
tmp="$ref[$index]"
echo "${!tmp}"# gives array element [2]
Re: Syntax Question...
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 wrong tool. It does not, in and of itself, mean that Bash is in some way flawed. Pliers and wrenches have some overlap in their capabilities, but you're better off using the one that's better suited for the task than to curse the design of the wrong one. We can be much more help if you provide specifics and omit *all* hyperbole. Show some code, describe *specifically* what the starting conditions are and what the desired *end* result is and we can fix your code. While Bash, like *all* software, has some bugs and even regressions, for most uses it's more than adequate. While I'm sure there are many successful, production 1500 line shell scripts, I would say that's getting into the size that they should have been written in something else or in some cases, better use of loops and functions would shorten them and make them more readable and maintainable. Also, don't worry about POSIX unless portability is an issue that you must contend with. If you are writing scripts for a well-defined environment in which you can safely expect certain dependencies to be met then go ahead and make full use of all the facilities available under those conditions. Please show some code. On Sun, Aug 14, 2011 at 10:15 PM, Linda Walsh wrote: > > > > ` 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 the combination. >>> > > > That's EXACTLY what I said -- it doesn't show anyway to do it, in fact, > it points the the exact problem I've been complaining about is bash's > instability > in it's extended features. I thought it would be like perl -- stable > progression, not > random jumps that break code. > > All he's saying is bash "shouldn't" or "can't (with any stability), but > used for > anything complex. > > He may be right. > > Personally I think it sucks. > > I was very happy with bash's extensions, and their progression -- right up > to this > last revision, when functionality was removed, and others functionality was > broken > > -- I USE tabs when typing a program into bash -- not all the time, but > now I can't -- in "single quotes", it tries to expand to all the words in my > curdir. > > The script I've been working on was suppose to be relatively simple -- but > given the all > the error checking I've been putting in, and all of the state tracking so a > run of the script wouldn't come in and corrupt what had been left by a > previous run, it's gotten ALOT more complex. > > Conceptually...about 8-10 lines of english, -> almost 1500 lines of bash > code -- MUCH of > which is to compensate for bashes new broken features. > > > One can claim it's my fault for not using POSIX, but I don't have this > problem in perl (the python people did...) maybe I haven't appreciated > how stable perl has been -- like C. > > But > 1) create snapshot > 2) look for oldest active snapshot > 3) rsync the diffs from the oldest snapshot compared against current to a > 'diff vol' > 4) create new 'static vol' sized to content on diff vol, and get rid of the > oldest active snapshot. > > > That's. IT! > > But... > .9) see if we have already created a snapshot today and require an override > flag > 3.5) label diff vol with content label of snapshot this came from. > with labeled diff vol, can remove old active snapshot (which needs to be > removed > before creating a new one w/same name & same mount point, but static)... > (could create new vol, and do renames, but would result in >lvm > fragmentation). > 2.8) before copying to diff dir -- make sure it is the correct mounted file > system and > delete it's contents (dependent on there being a "valid snap copy"...) > > which doesn't get set until the diff dir is copied to the new static stap > and IT gets > a label -- saying that the diff-copy completed successfully. > > etc. > etc. > etc... > > > It's just been growing... > (I didn't come close to listing all the checks that are in there now)... > > So conceptually --- looked like a simple shell script. > > but...to handle bash's broken error handling, all steps have to be > 'interlocked' -- > state 'checked' into a file system, and validated before going to the next > step. > > Otherwise, I end up with more problems than you want to know about. > >> >> Please try to be briefer and more on topic in your posts to this list, >> by the way. >> >> > > I'm stopping now. > Maybe not entirely on-topic, but I wasn't the one who started a side > conve
Re: Syntax Question...
` 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 it wrong in Bash or Bash is the wrong tool. It does not, in and of itself, mean that Bash is in some way flawed. Pliers and wrenches have some overlap in their capabilities, but you're better off using the one that's better suited for the task than to curse the design of the wrong one. We can be much more help if you provide specifics and omit *all* hyperbole. Show some code, describe *specifically* what the starting conditions are and what the desired *end* result is and we can fix your code. === I showed the high level plan in 4 lines Just that as I developed it, everything that could go wrong did, so I started writing to check itself and have interlocks. 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! ;-) My current snap - have been refusing to copy it over by hand as I keep thinking the script will get it. Then one more thing goes wrong. Takes almost a half an hour now to generate the diff vol @ about 3G of diff's, but rsync isn't a speed demon and it still has to compare 500G of files ... It's not like it is impossible to debug (though it REALLY doesn't help when leaving out a semi, or a set of parens somewhere only results in "unexpected end of file at line 417...(occasionlly 1113, but problems in that file are more rare, as I more often will write code in the main file and migrate it to the 2ndary file as a function when I have it working...). Please show some code. You didn't like my Short code:! that really was pretty much it!...honest... Lemme at least fix my typo...then I'll send the 2 files...oh...ummm.. they call some subfunctions...I'll try to get the deps..ARG(not deps) But 1) create snapshot 2) look for oldest active snapshot 3) rsync the diffs from the oldest snapshot compared against current to a 'diff vol' 4) create new 'static vol' sized to content on diff vol, and get rid of the oldest active snapshot.
Missing options in ulimit usage string
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bas$ uname output: Linux kid-charlemagne 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.2 Patch Level: 0 Release Status: release Description: `help ulimit` is missing the -b option in the usage string and is missing the -T option in both the usage string and the Options section of the help description. doc/FAQ in the bash 4.2 source tarball says both options were added in bash 4.0. Repeat-By: Run `help ulimit` and note that -b is listed in the Options section but not the usage string. Then look at doc/FAQ or the ulimit source and note that -T also exists but isn't documented. Fix: Attached is a patch to add usage documentation for -b and -T. I wasn't sure what to do about internationalization for the new text, so I left that alone for now. Having the usage string and Options match is an improvement, but it's a little confusing that you get an "invalid option" message when you use an option that isn't available on your platform, e.g.: $ ulimit -b bash: ulimit: -b: invalid option ulimit: usage: ulimit [-SHabcdefilmnpqrsTtuvx] [limit] To minimally address this I added a note in the help documentation that not all options are available on all platforms, but a more precise error message when using an option that doesn't exist on your platform would be better. Best regards, -Jessicadiff -ru ../bash-4.2/builtins/ulimit.def ./builtins/ulimit.def --- ../bash-4.2/builtins/ulimit.def 2010-05-30 18:26:37.0 -0400 +++ ./builtins/ulimit.def 2011-08-14 18:40:10.0 -0400 @@ -23,7 +23,7 @@ $BUILTIN ulimit $FUNCTION ulimit_builtin $DEPENDS_ON !_MINIX -$SHORT_DOC ulimit [-SHacdefilmnpqrstuvx] [limit] +$SHORT_DOC ulimit [-SHabcdefilmnpqrsTtuvx] [limit] Modify shell resource limits. Provides control over the resources available to the shell and processes @@ -46,11 +46,14 @@ -q the maximum number of bytes in POSIX message queues -r the maximum real-time scheduling priority -s the maximum stack size + -T the maximum number of threads -t the maximum amount of cpu time in seconds -u the maximum number of user processes -v the size of virtual memory -x the maximum number of file locks +Not all options are available on all platforms. + If LIMIT is given, it is the new value of the specified resource; the special LIMIT values `soft', `hard', and `unlimited' stand for the current soft limit, the current hard limit, and no limit, respectively. diff -ru ../bash-4.2/po/af.po ./po/af.po --- ../bash-4.2/po/af.po 2011-01-28 22:09:25.0 -0500 +++ ./po/af.po 2011-08-14 18:40:10.0 -0400 @@ -,7 +,7 @@ #: builtins.c:169 #, fuzzy -msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]" +msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" msgstr "Grootte beperk (Kb):" #: builtins.c:172 diff -ru ../bash-4.2/po/bash.pot ./po/bash.pot --- ../bash-4.2/po/bash.pot 2011-01-28 22:09:18.0 -0500 +++ ./po/bash.pot 2011-08-14 18:40:10.0 -0400 @@ -2094,7 +2094,7 @@ msgstr "" #: builtins.c:169 -msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]" +msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" msgstr "" #: builtins.c:172 diff -ru ../bash-4.2/po/bg.po ./po/bg.po --- ../bash-4.2/po/bg.po 2011-01-28 22:09:26.0 -0500 +++ ./po/bg.po 2011-08-14 18:40:10.0 -0400 @@ -2232,7 +2232,7 @@ msgstr "" #: builtins.c:169 -msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]" +msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" msgstr "" #: builtins.c:172 diff -ru ../bash-4.2/po/ca.po ./po/ca.po --- ../bash-4.2/po/ca.po 2011-01-28 22:09:27.0 -0500 +++ ./po/ca.po 2011-08-14 18:40:10.0 -0400 @@ -2224,7 +2224,7 @@ #: builtins.c:169 #, fuzzy -msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]" +msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" msgstr "ulimit [-SHacdfmstpnuv] [l?mit]" #: builtins.c:172 Binary files ../bash-4.2/po/cs.gmo and ./po/cs.gmo differ diff -ru ../bash-4.2/po/cs.po ./po/cs.po --- ../bash-4.2/po/cs.po 2011-01-28 22:09:27.0 -0500 +++ ./po/cs.po 2011-08-14 18:40:10.0 -0400 @@ -2210,8 +2210,8 @@ msgstr "type [-afptP] název [názevâ¦]" #: builtins.c:169 -msgid "ulimit [-SHacdefilmnpqrstuvx] [limit]" -msgstr "ulimit [-SHacdefilmnpqrstuvx] [limit]" +msgid "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" +msgstr "ulimit [-SHabcdefilmnpqrsTtuvx] [limit]" #: builtins.c:172 msgid "umask [-p] [-S] [mode]" Binary files ../bash-4.2/po/de.gmo and ./po/de.gmo differ diff -ru ../bash-4.2/po/de.po ./po/de.po --- ../bash-4.2/po/de.po 2011-01-28 22:09:28.0 -0500 +++ ./po/de.po 2011-08-14 18:40:10.000
