Timeline for (Bash) For Loop Not Functioning Properly
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2019 at 14:22 | vote | accept | Jack Rolph | ||
| Oct 1, 2019 at 13:09 | answer | added | ilkkachu | timeline score: 2 | |
| Oct 1, 2019 at 12:41 | comment | added | user232326 |
@Kusalananda I believe in the motto: enforce your assumptions. The function foo was written under the assumption that expansions would be split on spaces, setting IFS enforces that assumption. That breaks nothing else (if changed with local) outside foo, not even if IFS was/is @. That IFS got changed, or not, at some other point of the script should be corrected, also, at some other point of the script.
|
|
| Oct 1, 2019 at 12:35 | history | edited | Jack Rolph | CC BY-SA 4.0 |
added 866 characters in body
|
| Oct 1, 2019 at 12:27 | comment | added | Jack Rolph | I have tried setting the local IFS, but there remains a problem. | |
| Oct 1, 2019 at 12:21 | comment | added | Kusalananda♦ |
@Isaac Well, it makes the code in question work. Other statements in the scirpt may break due to IFS having been changed from @...
|
|
| Oct 1, 2019 at 12:13 | comment | added | user232326 |
@Kusalananda From this OP comment: If I run foo from bar, then the error occurs. This occurs irrespective of using bash program.sh or . program.sh. it seems to me that the program.sh is allways executed (not sourced) but at some point while testing the script test.sh (not program.sh) at some point the user executed . program.sh which trigered the un-noticed change of IFS, and, thus, his description. ... In any case, a local IFS=$' \t\n' inside foo makes the script more robust.
|
|
| Oct 1, 2019 at 12:12 | comment | added | Jack Rolph |
Perfect solutions! I had set IFS=@ to allow some menus to run. Changing instances of IFS=@ to local IFS=@ where necessary solved the problem.
|
|
| Oct 1, 2019 at 11:59 | comment | added | user232326 |
Or better yet, since this is bash, do the change local to the function: make the first line of foo read local IFS=$' \t\n'. The value will return to what it was before when the function exit.
|
|
| Oct 1, 2019 at 11:55 | comment | added | Kusalananda♦ |
@Isaac IFS is probably set to a non-default value in the interactive shell. What I would want to know if why they are sometimes sourcing the script and sometimes not. That part makes no sense.
|
|
| Oct 1, 2019 at 11:53 | comment | added | user232326 |
Then, something is changing IFS before the seq command. Probably (not knowing all the details of the 2000 lines script) you can re-set IFS=$' \t\n' to its default value.
|
|
| Oct 1, 2019 at 11:36 | comment | added | Siva | Then u should have changed/assigned IFS to @ in somewhere in the nonworking script... | |
| Oct 1, 2019 at 11:27 | comment | added | Jack Rolph |
The output it simply IFS: @ in the non working case and IFS: $' \t\n' in the working case
|
|
| Oct 1, 2019 at 11:12 | comment | added | ilkkachu |
check what your IFS is in the working and the non-working case. Put something like printf "IFS: %q\n" "$IFS" in front of the for loop
|
|
| Oct 1, 2019 at 11:10 | comment | added | Jack Rolph | The whole thing is 2000 lines long - I can do this if it would help? | |
| Oct 1, 2019 at 11:05 | comment | added | Kusalananda♦ |
You would get that error if you double-quoted the command substitution of seq, i.e. for chunk in "$( seq ... )". Could you double check that you are showing us the code that you are running?
|
|
| Oct 1, 2019 at 11:05 | comment | added | Siva | for me the given code is working well... | |
| Oct 1, 2019 at 11:00 | review | First posts | |||
| Oct 1, 2019 at 11:27 | |||||
| Oct 1, 2019 at 10:55 | history | asked | Jack Rolph | CC BY-SA 4.0 |