Array not defined when being set inline
I guess that's the right way to describe what I'm seeing:
[swilson@localhost ~]$ unset f; f=(aaa bbb ccc) declare -p f
declare -x f="(aaa bbb ccc)"
[swilson@localhost ~]$ unset f; f=("aaa" "bbb" "ccc") declare -p f
declare -x f="(aaa bbb ccc)"
[swilson@localhost ~]$ unset f; f=(aaa bbb ccc)
[swilson@localhost ~]$ declare -p f
declare -a f='([0]="aaa" [1]="bbb" [2]="ccc")'
Is this known? What exactly is going on / what does this mean?
Re: Array not defined when being set inline
On Tue, Oct 10, 2017 at 8:21 AM, Greg Wooledge wrote: > On Tue, Oct 10, 2017 at 08:00:58AM -0400, shawn wilson wrote: >> I guess that's the right way to describe what I'm seeing: >> >> [swilson@localhost ~]$ unset f; f=(aaa bbb ccc) declare -p f >> declare -x f="(aaa bbb ccc)" > > You placed a string variable in the temporary execution environment of > the declare command. If you wanted an actual array variable that would > persist past this command, you need a semicolon or newline after the > assignment, and before the declare command. > Nope, I knew how to correct it (as I showed in the last example), I just figured the other two should work. > > See also: http://mywiki.wooledge.org/BashFAQ/104 Thanks for that (and the link it provides to BashParser - I'm going to have to digest that). Is there a way to detect that the parser has already processed a temporary variable and maybe change the exit status or something?
unset does not act as expected on namerefs
swilson@swlap1:~/temp$ bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) swilson@swlap1:~/temp$ cat t.txt $ome text !n a file| swilson@swlap1:~/temp$ unset t swilson@swlap1:~/temp$ t=$(< ./t.txt) swilson@swlap1:~/temp$ echo "$t" bash: $ome text !n a file|: invalid variable name for name reference swilson@swlap1:~/temp$ var=foo; declare -n t; t=var; unset t; echo "$t" bash: $ome text !n a file|: invalid variable name for name reference pgpk4Cwu_mrnZ.pgp Description: PGP signature
Re: unset does not act as expected on namerefs
On +2015/05/26 11:04:38, Greg Wooledge wrote: > On Tue, May 26, 2015 at 10:31:34AM -0400, Shawn Wilson wrote: > > swilson@swlap1:~/temp$ bash --version > > GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > > swilson@swlap1:~/temp$ cat t.txt > > $ome text !n a file| > > swilson@swlap1:~/temp$ unset t > > swilson@swlap1:~/temp$ t=$(< ./t.txt) > > swilson@swlap1:~/temp$ echo "$t" > > bash: $ome text !n a file|: invalid variable name for name reference > > swilson@swlap1:~/temp$ var=foo; declare -n t; t=var; unset t; echo "$t" > > bash: $ome text !n a file|: invalid variable name for name reference > > As surprising as that is, have a look at "help unset": > So current behavior should stand? I would think that unset (with no options) should DWIM. This behavior also seemed to surprise most on #bash IRC. This is not a bug for lack of documentation or not understanding the results after looking at the doc, but a "wow, this is surprising - maybe this could behave in a manner so it's not so surprising". > unset: unset [-f] [-v] [-n] [name ...] > Unset values and attributes of shell variables and functions. > > For each NAME, remove the corresponding variable or function. > > Options: > -ftreat each NAME as a shell function > -vtreat each NAME as a shell variable > -ntreat each NAME as a name reference and unset the variable > itself > rather than the variable it references pgpTDG5rNHwS4.pgp Description: PGP signature
Re: unset does not act as expected on namerefs
On +2015/05/26 18:05:18, Geir Hauge wrote: > On Tue, May 26, 2015 at 11:00:45AM -0500, Eduardo A. Bustamante López wrote: > > # Here we 'unset ref', which actually unsets 'var'. Then, we assign 'var' to > > # 'ref', but since 'ref' is still a nameref, it instead assigns 'var' to > > 'var'. > > dualbus@hp:~$ unset ref; ref=var; echo "$ref"; declare -p ref > > var > > declare -n ref="var" > > dualbus@hp:~$ declare -p var > > declare -- var="var" > > Ah, that explains it! Mystery solved, and no longer surprising behavior. > If there's no good reason to keep this as is (some use case where this might be wanted and breaking backward compatibility - I can't see anyone actually *wanting* it this way) shouldn't it be changed? A behavior can be documented and still be bad. pgpOwZAk14bLp.pgp Description: PGP signature
Re: unset does not act as expected on namerefs
Top posting as I'm kinda going out of band of the thread here; Having read the discussion, I guess the issue I brought up really isn't a "bug" (though Greg's points probably should be considered bugs). I'll preface this by saying I'm not an expert in bash by any means. However, most languages have a garbage collection facility which cleans up anonymous refs with nothing pointing to it and most high level languages make it easier to make a soft or symbolic reference than making hard references. But also, when you 'undef'/delete()/whatever the variable or the pointer, handle both and avoid this issue. While I do like the idea of pointers for bash variables, I would much prefer being able to create references. Also, whatever happens, I think there should also be a way to test for variable type (either another test flag or something like perl's ref() ). Feel free to flame me and say 'go away' if I'm off the mark with how this should be handled :) -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQMuBFDPieoRCACpmirxE3mrgdr2QZ1EuKOdD7m9nTsnXOVBkezonaDH/iEDlvZE KAiS3cuZKJ9aQ5rsfs12fX62Gnj9ulRcNr3lBc8LdgGFiq84wodF25faaUc43HDS 04tOhXpzH5f62tSUAIFpTggbIWbawH0Ojl96G5RivUS1RY5eObrH3mH/MmiT++r1 tRrviDlJ8P/qmimF6AejV/H0w5HmEpUUx1n1Rl+RndVCdjT2s5eOsFdsCRJJLJBi LPVmJufvaL6Xk27BKjCz6Msn8JqaM9vKYO894M7KCKGSS14mziXL15GMi564AuD8 eWep7dnLBWyD9fBoyXTtxcp/Ls2K5Qd3REIbAQDHqV2Fw8ewxD5KE57tLoxg+N1U 7Dnd9fTDiVq4alALEQf/cmZhzXVwBQ50kiiR2kD5MgVMYTDDtibuqRl7QfENyX2f leC0vqN0YVEZk4Ykh4FNNuM50eGRWUCOu7yA6/qpDvUJzFof9LOlPL3rNvhajPWE BjBR/sG0NZewFaHQtuXLm9XsSmcV5XscX+YqJgMpN4G2qfzQs+zwYslOo77lIUcS ErQlkPI3iTs7AcLiimtILh/eH7vzlqRYDB8WoILEXSDXuB8X2GcLyo+Y8fFpb5Vf 8/mSr59aSrsSMtMqQAnh26VdtrICJMfd8zl9vgaa4+BeBl4kOol1aSS2UY5AL0Uu oaViBuH3cgtX3C8TpvmqeKuVdx8SsvX3CGEmj6C/nAgAqP8OXYn41dle537/WGYx RPlEgxnv8/xD0KTnr07EBHcd1ZbQzcjq5EBrNMiu8VgbIXuL0mhz21TkZfFMSThP x4RTxNTYlLrwKVDYp8QQbK35BpoDj33OFqa255qA3O324iSJupdsNvVj0QAIXjz0 GvKbEEMAkYp7jgbGcZsLKOjn7xF9aLZE3yU+0CrWNwwgwTZULEm4Jql6YQdA96jb UtHtOhxH6q1+T5sd2c8fukxQj9NnRON0fcMT1anI1oeDsGj1UlqLkIOyWY3oacD6 yx3HtzY2hY9kQimKcz5Ycrg4iZP1Rig2mbr+9KN6x1QQmcSuRFXFli4aTd01h1eS FrQkU2hhd24gV2lsc29uIDxzd2lsc29uQGtvcmVsb2dpYy5jb20+iIEEExEIACkF AlDPieoCGwMFCQeEzgAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAlESJy emO7FAFCAQCQZmLAslVd4DOjIp1xzFE7EH0L1atjjJ6NZpCooDsRLQD/QkwDZdM5 4VfLLVrL5GsKAuoCfKO6ZT/IvA6I8bKE8NKJARwEEAEIAAYFAlDPjs0ACgkQLVcy 4WhrbbPTqQf9FD4foqu0YzOZx/MFZdakBLynBvdEEyQgMO39yCKuFh68c0JN35yc OmcFzTClq2s2yAbKZwPJAg3YDYowVfubqbVm1E5+ZuWJOwJkItcQTBkVTmAt7G+r cSa/yHgh+El2J3+2fiUsUQNdeIwiAOMoAKmpkPfXm7mBapUur81e4NLK8XBc2dw7 ZHFie64588c0hkAyfXXJjgy1Uwv5dCIO2u02hnUgXf3/eAQS8FLV1pym50iw9Rha D9DYtIYcHsLMUI3ER2QgyTAUbWlUR4xONqgI+lIgCXDpMR3vuzxcOQD7f6fqbIz5 FAx0/9IqY92YD4DN2dwWpjyUZJ2gplBNUokBHAQQAQIABgUCUNDdyAAKCRBqqcNw vQYcS15/B/40YopvQbDOUMfd2pGgwfwvbjZnwz9FxBolU8wYGugFc2j3Oi/Zu95Y yCOHfnjBIeBaM0ORop/NHDOcfO+PWPqjZYEENoPcJTKNd+Eh4wZDw6tqpbvcTV0Y 0HxZeSau7ayji6spMOWkR2PHOOl5t0BLaUx50A0Cl3ihhKXHpAQLwWFvvf8gf5SP yZG0Mx91a22jbq4ZKwvFWYVLI98lMW2GciPBWOXvKAbwMqD23wzeI4F+HhnA2nVl QtFS0NRweo4y3pVJdRkQAg5FQAUkMtGUkn9GxmcqXOkwAEzYtuAMrPgPLUjBdxBe 17wChh2irtDahCssQr+Sqo5Ja2JlRSu2iQEcBBABAgAGBQJQ0OZyAAoJEJ6iZzj1 QlX2S3AH/jjg76zRn2nduf3sF9XtNP6KsiFdqJy6JlJZTlBjelN2aHFq5raIb63G NKLnzdk2rGteUtHN5dFKSFOUMNRKl8Bx7QLnCjiYNWMH3I11U5dAm3ugv68QPuGo BVqc1Hz9+vWb6CwCUka0apgF58s8+msg8PDWjtSkBoq0jEgXoii3BDJZOau05GWo lhgmHvE9JAF74QOv/LkGzsV9JzrTcr8I82biW9O3UxhJWD8Hqf9Lw9JD686Vubk8 /lrS8ikxdDzghYgFs5z0xzHjMb/1nBYmwVLdVKssTC736tMIlxHoYpfguKG5IZBk 7EhN7EdLRfpVrDBHmQoxC+IrUN5VpIeJARwEEAECAAYFAlEj7ZcACgkQQHQYvODE t5GvwAf/dHtEh104FaUsXcwemk9UJpKgwt2EiRZWVYAcOsm+dHJBgMR7MJzbEjtA YjwcYy+bnyjPpbRh6z7RZiljaHvMQSI9/lwk9+yP3R104JBUr6XynA3tAqXhl+Oq cWBiR/V0N4lBmtpDMI32FaBV7hM3A3XvNEv/EV8SGoRkFofbSQCEHbJyx5Xy3MyD sMn8j4NYBdWDo2E7vU7VnIopM+PPwjMrMzlVXlBrK2s039IcAi5UZMAk3DnDfxpR DKkL+3c7mtpRHFiXtU3Wk8LBowyWiq7PX0guj87C6Xpfr7HO1UnNpi2x1yh0syd2 4bJ70KfLGHxwCbG6SKBgNRlRwm66XbQpU2hhd24gV2lsc29uIDxzaGF3bi53aWxz b25Aa29yZWxvZ2ljLmNvbT6IgQQTEQgAKQUCUM+MyAIbAwUJB4TOAAcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJECURInJ6Y7sUO3QA/27xcBy/inCpptTxPqxl M1OVbby0z25zErqOz0xHu8KCAP9H0U0YDQ7yHesROJDdeRbVxPrh5/X/sdCXZb5m nul+QYkBHAQQAQgABgUCUM+OzQAKCRAtVzLhaGtts2XPB/98Tiyw2wdVP8uTzSXz bFd51M6wWo1ykwS04oXiqt2+qb3sLRdnO0D4Ao+07klPEEcp3Lz7eGJhvvmH51IY fN/l56byEmP4rVFCgk5lZPlnR3J235DH4xIK/Al4ppMLIPIYRUUjdmI018l1LwT9 H5ayQOl8E/5AgKvW7VAYaPK5MhWH2fKag3goTeNoOEGN/4YM57ICfC5prfAzMWsg /GmV14C7rP2Fio4XcSS4vaWPkMY9rGJ7ZsRa6TQC3GNir61O9UMOmGlKoFfer22b 8GHtg2TkzOLT6GjfVnlIrXAdc5gJDkVsCgRs2OzRzIPwERH+JsSTMtzha5XamlaH qEuiiQEcBBABAgAGBQJQ0N3IAAoJEGqpw3C9BhxL0bMH/i9K/0vrsZFpJrCx2T64 IpTl4Ynr7a0gI8e5G2F6woe/WZnEEa/HgXST12O2ouTlM77sGX6y9L99tBkX6GlB ZrYvdHXOhtosJeUcst0WrZSR2xs5/5aQYxS1aGvHKBvnRRUPgVCK9mW++vr/JLU/ 9LMjozDEq+1FxvtgQGVXJ2Xc5HgfDCm71hFzHce6TKlk2TCakZEV1iluh6k1QdyX WZkxk89+aB0hVgJs8Aq++M1bMY6XXPC8SjIF7Ax71WdXMFzRuNYVhsevhohGzgHX SDZqczTUD7W8crXpk2yf6l9fVgBSI8WzX0fE5faAUbuOVdNYWC18Xk9WKCn0rttJ JieJARwEEAECAAYFAlDQ5nIACgkQnqJnOPVCVfZkWwf9H6F7usmMTAA1oWGOAK2U BM11LSajiKSbeGELAuG
Re: unset does not act as expected on namerefs
On +2015/06/02 08:31:57, Greg Wooledge wrote: > > > Also, whatever happens, I think there should also be a way to test > > for variable type (either another test flag or something like perl's > > ref() ). > > Bash is not a strongly typed language. You've got strings, and indexed > arrays, and associative arrays. That's all. (There's declare -i, but > no sane person USES that, so we can ignore it.) > > You might be trying to do things that Bash is simply not designed to do. > It's a shell. I would argue that a nameref is a variable type. pgpmvsk0XMiMp.pgp Description: PGP signature
bug with getting an array index or ...
declare -a array=( ); echo "${!array[@]}";
echo "${!array[@]:-}"
also, "${!array[@]:foo}" and :+foo and :-foo are all empty as well -
I'm pretty sure this is not intended?
Re: scripts one after the other
On Mar 25, 2016 9:32 PM, "Val Krem" wrote: > > At the present I have defined the variables and folders path in both scripts. > > Instead of this, is it possible to combine the two scripts in one so that I can define the varietals at one spot. It would be less prone to error. > What I've done is source a config file with my variables defined. > The problem that I have now is that I want to see the output of job1 script before preceding the next process. I want insert a question if I want to proceed to the next execution. If I say no let the script stop processing otherwise continue to the next command. I'm not sure what you want, but you could always pipe one script into another and evaluate the input from the later. Or just call the second script from the first in an if.
Re: scripts one after the other
On Sat, Mar 26, 2016 at 9:26 AM, Val Krem wrote: > > I'm not sure what you want, but you could always pipe one script into > another and evaluate the input from the later. Or just call the second > script from the first in an if. > (untested) #!/bin/bash # t2.sh read f if [[ $f == foo ]] ; then ... fi $ t1.sh | t2.sh Or #!/bin/bash # t1.sh . # do stuff if ; then ./t2.sh fi $ t1.sh > > It is not the question of PIPE one script to the other. I want to pause the > script and see the result then decide to continue or not. >
