BASH script segment won't work in larger script

EdH · 2021-10-02, 16:20

I have the following in a BASH script:

Code:

      echo "c4 is $c4 and am is $am"
      c4m=$(../../yafu/yafu "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"

It doesn't work anywhere* in that 800+ line script:

Code:

c4 is -2293531595601876 and am is 3
c4 is -2293531595601876 and c4m is no variable indicator (@): interpreting batchfile lines as input expressions
eof; done processing batchfile

But, if I try the exact copy/pasted lines in a small test script (adding in the required values):

Code:

#!/bin/bash

c4=-2293531595601876
am=3
      echo "c4 is $c4 and am is $am"
      c4m=$(../../yafu/yafu "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"

it works exactly as expected:

Code:

c4 is -2293531595601876 and am is 3
c4 is -2293531595601876 and c4m is -6880594786805628

I'm (pretty) sure this isn't a YAFU issue, so I'm posting here.

* I have tried these lines in two functions and in various locations in the main body of the larger script with no success. The scripts are located in the same directory.

All thoughts welcome. . .

fivemack · 2021-10-02, 19:01

Quote:

Originally Posted by EdH

I have the following in a BASH script:

Code:

      echo "c4 is $c4 and am is $am"
      c4m=$(../../yafu/yafu "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"

It doesn't work anywhere* in that 800+ line script:

Code:

c4 is -2293531595601876 and am is 3
c4 is -2293531595601876 and c4m is no variable indicator (@): interpreting batchfile lines as input expressions
eof; done processing batchfile

But, if I try the exact copy/pasted lines in a small test script (adding in the required values):

Code:

#!/bin/bash

c4=-2293531595601876
am=3
      echo "c4 is $c4 and am is $am"
      c4m=$(../../yafu/yafu "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"

it works exactly as expected:

Code:

c4 is -2293531595601876 and am is 3
c4 is -2293531595601876 and c4m is -6880594786805628

I'm (pretty) sure this isn't a YAFU issue, so I'm posting here.

* I have tried these lines in two functions and in various locations in the main body of the larger script with no success. The scripts are located in the same directory.

All thoughts welcome. . .

What happens if you replace the '$(../../yafu/yafu' with '$(echo' ? That error message is coming from yafu not from bash (that is, yafu's output is that error message and has been captured into $c4m), so it looks as if the thing going into yafu has been somehow garbled ...

EdH · 2021-10-02, 20:18

Quote:

Originally Posted by fivemack

What happens if you replace the '$(../../yafu/yafu' with '$(echo' ? That error message is coming from yafu not from bash (that is, yafu's output is that error message and has been captured into $c4m), so it looks as if the thing going into yafu has been somehow garbled ...

I cannot detect a difference. Script that works:

Code:

c4 is 2346021463111956 and am is 3
c4 is 2346021463111956 and c4m is expr(2346021463111956*3) -silent
c4 is 2346021463111956 and c4m is 7038064389335868

and, script that doesn't work:

Code:

c4 is 2346021463111956 and am is 3
c4 is 2346021463111956 and c4m is expr(2346021463111956*3) -silent
c4 is 2346021463111956 and c4m is no variable indicator (@): interpreting batchfile lines as input expressions
eof; done processing batchfile

Code in both scripts:

Code:

am=3
      echo "c4 is $c4 and am is $am"
      c4m=$(echo "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"
      c4m=$(../../yafu/yafu "expr($c4*$am)" -silent)
      echo "c4 is $c4 and c4m is $c4m"

I've also tried this with both YAFU 1 and YAFU 2 with identical results.

I fully agree with your assessment. That's why I didn't consider it a YAFU issue. But, I can't figure out what's wrong with the calling script. I'm thinking of using a separate script file to work around this, instead of embedding it in the main script.

Thanks!

EdH · 2021-10-03, 12:20

I'm guessing it's my personal gremlin screwing with me. I wrote a separate script just to perform the task for my main program and it won't work, either. The only difference I can think of is the way the variables are assigned. In the working script, the variables are directly assigned their value. In the broken scripts, the value is acquired via parsing. The best I can come up ATM, is that there is some "invisible" artifact in the parsed values.

M344587487 · 2021-10-03, 12:32

At first I thought you were using the expr utility and passing a number to yafu so noodled with that, but you're actually passing the string "expr(a*b)" to be evaluated by yafu (?) (sorry, unfamiliar with yafu). Either way you may need to delimit * so that it doesn't get substituted by the shell, and/or include spaces between the variables and the operator if yafu works like expr. Any difference in how you're calling the scripts that may let one substitute and the other not?

Code:

u20@u20:~/textdir$ jam="$(expr -2293531595601876 * 3)";echo $jam
expr: syntax error: unexpected argument ‘file_in_cd’

u20@u20:~/textdir$ jam="$(expr -2293531595601876 \* 3)";echo $jam
 -6880594786805628

u20@u20:~/textdir$ jam="$(expr -2293531595601876\*3)";echo $jam
-2293531595601876*3

EdH · 2021-10-03, 15:28

I've tried lots of variations including \*, but mostly, they don't work with YAFU.

I'm still confused as to what the difference may be between a specific variable initialization and the variable coming from an operation. The two variables "appear" identical, but don't work the same. Oddly, I have used this in the past and it worked fine there. I need to see if I can find any of those scripts and see if I can learn anything from them.

chris2be8 · 2021-10-03, 16:06

What happens if you add set -x to the script? It should show you what the shell thinks the command it's executing is. Try it both in the small working script and the big one where it does not work. See the man page for bash for details (search for "SHELL BUILTIN COMMANDS" and scroll down).

EdH · 2021-10-03, 17:00

Quote:

Originally Posted by chris2be8

What happens if you add set -x to the script? It should show you what the shell thinks the command it's executing is. Try it both in the small working script and the big one where it does not work. See the man page for bash for details (search for "SHELL BUILTIN COMMANDS" and scroll down).

Thanks - I'll play with this and see what it shows.

For the time being, unless the above gets me some good info, I have come up with a solution in the following way:

I know the following:

Code:

"expr($test*$m)" | ../../yafu/yafu

will give the earlier complaint about a bathchfile, but it will also provide the answer within all the generated lines. The good part is that the answer is in the same element, if I parse the return via an array. I can harvest it from the array in a consistent manner.

I will probably run with this solution for now, unless I can easily find why the earlier script versions don't work and correct it.

EdH · 2021-10-03, 18:07

Quote:

Originally Posted by chris2be8

What happens if you add set -x to the script? It should show you what the shell thinks the command it's executing is. Try it both in the small working script and the big one where it does not work. See the man page for bash for details (search for "SHELL BUILTIN COMMANDS" and scroll down).

Well, set -x showed that the exact same expression is sent to YAFU, but with different results:

Code:

+ ../../yafu/yafu 'expr(756756*3)' -silent
2270268
...
+ ../../yafu/yafu 'expr(756756*3)' -silent
no variable indicator (@): interpreting batchfile lines as input expressions
eof; done processing batchfile

chris2be8 · 2021-10-04, 15:48

My knowledge of shell scripting has nearly run out. But there must be *something* in the big script that is affecting yafu. Have you done anything with stdin or stdout in the big script? Try adding </dev/null to the yafu call. And look for anything else that could affect yafu. You could try cutting a copy of the big script down by deleting bits of it until yafu works (hopefully before it's the same as the small script!)

Sorry I've run out of ideas.

kruoli · 2021-10-04, 16:25

Have a look at line 855 of driver.c, it says if (isatty(fileno(stdin)) == 0) (in my current GIT checkout), and this is the only point where is_cmdline_run gets set to 2 and 2 is the only value which leads to yafu_obj.USEBATCHFILE being set to 2 (also the only occurence), the other possible value for yafu_obj.USEBATCHFILE would be 1, but we can assume that it is not 1, because you have not set the batchfile option. So we enter the if in line 230, which is the only place where prepare_batchfile gets called, and this is the only place where the message "no variable indicator (@) ..." gets printed.

If I am correct here, it will follow that isatty(fileno(stdin)) is something != 0 (likely 1) when executing directly for you and 0 when executing in your script. I checked that with my Debian WSL and could not reproduce that. Are you piping something into the script? Or are you accessing stdin at any place in the script?

2021-10-02, 16:20	#1
EdH "Ed Hall" Dec 2009 Adirondack Mtns 7·751 Posts	BASH script segment won't work in larger script I have the following in a BASH script: Code: echo "c4 is $c4 and am is $am" c4m=$(../../yafu/yafu "expr($c4$am)" -silent) echo "c4 is $c4 and c4m is $c4m" It doesn't work anywhere in that 800+ line script: Code: c4 is -2293531595601876 and am is 3 c4 is -2293531595601876 and c4m is no variable indicator (@): interpreting batchfile lines as input expressions eof; done processing batchfile But, if I try the exact copy/pasted lines in a small test script (adding in the required values): Code: #!/bin/bash c4=-2293531595601876 am=3 echo "c4 is $c4 and am is $am" c4m=$(../../yafu/yafu "expr($c4$am)" -silent) echo "c4 is $c4 and c4m is $c4m" it works exactly as expected: Code: c4 is -2293531595601876 and am is 3 c4 is -2293531595601876 and c4m is -6880594786805628 I'm (pretty) sure this isn't a YAFU issue, so I'm posting here. I have tried these lines in two functions and in various locations in the main body of the larger script with no success. The scripts are located in the same directory. All thoughts welcome. . .

2021-10-03, 12:32	#5
M344587487 "Composite as Heck" Oct 2017 3×311 Posts	At first I thought you were using the expr utility and passing a number to yafu so noodled with that, but you're actually passing the string "expr(ab)" to be evaluated by yafu (?) (sorry, unfamiliar with yafu). Either way you may need to delimit so that it doesn't get substituted by the shell, and/or include spaces between the variables and the operator if yafu works like expr. Any difference in how you're calling the scripts that may let one substitute and the other not? Code: u20@u20:~/textdir$ jam="$(expr -2293531595601876 * 3)";echo $jam expr: syntax error: unexpected argument ‘file_in_cd’ u20@u20:~/textdir$ jam="$(expr -2293531595601876 \* 3)";echo $jam -6880594786805628 u20@u20:~/textdir$ jam="$(expr -2293531595601876\3)";echo $jam -22935315956018763

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Startup Script	Gerard	Information & Answers	2	2018-11-01 08:40
Simple Script to get Trial Factoring Work	jfamestad	PrimeNet	3	2016-11-06 20:32
bash script for extracting primenet-status	gLauss	Linux	0	2010-07-31 11:19
Could you help me change this into a bash script?	jasong	Programming	1	2007-11-29 05:59
Help with Startup Script	Proggie	Software	1	2004-12-19 11:54

2021-10-03, 12:20	#4
EdH "Ed Hall" Dec 2009 Adirondack Mtns 1010010001001₂ Posts	I'm guessing it's my personal gremlin screwing with me. I wrote a separate script just to perform the task for my main program and it won't work, either. The only difference I can think of is the way the variables are assigned. In the working script, the variables are directly assigned their value. In the broken scripts, the value is acquired via parsing. The best I can come up ATM, is that there is some "invisible" artifact in the parsed values.

2021-10-03, 15:28	#6
EdH "Ed Hall" Dec 2009 Adirondack Mtns 7·751 Posts	I've tried lots of variations including \*, but mostly, they don't work with YAFU. I'm still confused as to what the difference may be between a specific variable initialization and the variable coming from an operation. The two variables "appear" identical, but don't work the same. Oddly, I have used this in the past and it worked fine there. I need to see if I can find any of those scripts and see if I can learn anything from them.

2021-10-03, 16:06	#7
chris2be8 Sep 2009 3·809 Posts	What happens if you add set -x to the script? It should show you what the shell thinks the command it's executing is. Try it both in the small working script and the big one where it does not work. See the man page for bash for details (search for "SHELL BUILTIN COMMANDS" and scroll down).

2021-10-04, 15:48	#10
chris2be8 Sep 2009 3·809 Posts	My knowledge of shell scripting has nearly run out. But there must be something in the big script that is affecting yafu. Have you done anything with stdin or stdout in the big script? Try adding </dev/null to the yafu call. And look for anything else that could affect yafu. You could try cutting a copy of the big script down by deleting bits of it until yafu works (hopefully before it's the same as the small script!) Sorry I've run out of ideas.

2021-10-04, 16:25	#11
kruoli "Oliver" Sep 2017 Porta Westfalica, DE 2²×3²×37 Posts	Have a look at line 855 of driver.c, it says if (isatty(fileno(stdin)) == 0) (in my current GIT checkout), and this is the only point where is_cmdline_run gets set to 2 and 2 is the only value which leads to yafu_obj.USEBATCHFILE being set to 2 (also the only occurence), the other possible value for yafu_obj.USEBATCHFILE would be 1, but we can assume that it is not 1, because you have not set the batchfile option. So we enter the if in line 230, which is the only place where prepare_batchfile gets called, and this is the only place where the message "no variable indicator (@) ..." gets printed. If I am correct here, it will follow that isatty(fileno(stdin)) is something != 0 (likely 1) when executing directly for you and 0 when executing in your script. I checked that with my Debian WSL and could not reproduce that. Are you piping something into the script? Or are you accessing stdin at any place in the script?