How to use SET VARIABLE when variable have spaces

I am trying to use AGI to get a text on asterisk, the problem is that the text have spaces between the words and looks like asterisk can not read it.

extensions.conf

exten => *24,1,AGI(test)
 same => n,NoOp(TEXT: ${TEXT})

/var/lib/asterisk/agi-bin/text

#!/bin/bash

TEXT='hello world'

echo "SET VARIABLE TEXT $TEXT"

asterisk -r

[2022-04-05 11:27:35]     -- Executing [*24@ddd:1] AGI("SIP/7050-000009dd", "test") in new stack
[2022-04-05 11:27:35]     -- Launched AGI Script /var/lib/asterisk/agi-bin/test
[2022-04-05 11:27:35]     -- <SIP/7050-000009dd>AGI Script test completed, returning 0
[2022-04-05 11:27:35]     -- Executing [*24@ddd:2] NoOp("SIP/7050-000009dd", "TEXT: ") in new stack

If I change the text to a sinle word it work:

#!/bin/bash

TEXT='hello'

echo "SET VARIABLE TEXT $TEXT"

asterisk -r

[2022-04-05 11:42:05]     -- Executing [*24@ddd:1] AGI("SIP/7050-000009e2", "test") in new stack
[2022-04-05 11:42:05]     -- Launched AGI Script /var/lib/asterisk/agi-bin/test
[2022-04-05 11:42:05]     -- <SIP/7050-000009e2>AGI Script test completed, returning 0
[2022-04-05 11:42:05]     -- Executing [*24@ddd:2] NoOp("SIP/7050-000009e2", "TEXT: hello") in new stack

I tried use single quotes around $TEXT, put $TEXT outside of the echo double quotes, and other ways without success.

Is it possible to pass a variable to asterisk where the variable have spaces? How do I do that?

  1. If you enable AGI debugging on the console (‘agi set debug on’) you will see the ‘conversation’ between your AGI and Asterisk.

  2. You will profit from reading about the AGI protocol. Your snippet violates the protocol in a couple of ways. It may work for something as simple as a single ‘set variable’ but not following the protocol may fail in unexpected and difficult to debug ways.

  3. Bash (IMO) is not a great language for writing AGIs. I would suggest one of the ‘P’ languages with a AGI library. I’m sure others may have had success in minor projects, but do you really want to ‘swim upstream?’

  4. Properly using an existing library is the path to success in AGIs.

  5. Your specific error is caused by not quoting $TEXT correctly in your echo statement.

Thanks:

  1. I did not know about this command, I will use.
  2. Rarely I use AGI and when I needed it was for simple answers.
  3. I tried to script in php, got the same error:
  4. I do not like the idea of have to recur to a library to this simple request where the answer come in a sentence insted a word, I would like to have control of the script and not depend of external fonts.
  5. I thought about that, but didn’t find a way to make it work, for exemple:
echo "SET VARIABLE TEXT '$TEXT'"
[2022-04-05 14:29:51]     -- Executing [*24@ddd:1] AGI("SIP/7050-000009f9", "test") in new stack
[2022-04-05 14:29:51]     -- Launched AGI Script /var/lib/asterisk/agi-bin/test
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_request: test
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_channel: SIP/7050-000009f9
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_language: pt_BR
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_type: SIP
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_uniqueid: 1649179791.38258
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_version: 16.24.0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_callerid: 7050
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_calleridname: Celso Annes
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_callingpres: 0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_callingani2: 0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_callington: 0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_callingtns: 0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_dnid: *24
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_rdnis: unknown
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_context: ddd
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_extension: *24
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_priority: 1
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_enhanced: 0.0
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_accountcode:
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> agi_threadid: 139814231230208
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >>
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Rx << SET VARIABLE TEXT 'hello world'
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> 520-Invalid command syntax.  Proper usage follows:
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> Sets a variable to the current channel.
[2022-04-05 14:29:51] <SIP/7050-000009f9>AGI Tx >> 520 End of proper usage.
[2022-04-05 14:29:51]     -- <SIP/7050-000009f9>AGI Script test completed, returning 0
[2022-04-05 14:29:51]     -- Executing [*24@ddd:2] NoOp("SIP/7050-000009f9", "TEXT: ") in new stack
[2022-04-05 14:29:51]     -- Auto fallthrough, channel 'SIP/7050-000009f9' status is 'UNKNOWN'

If your PHP script sent the exact same request, I would expect the exact same response :slight_smile:

I was proposing that a ‘P’ language + an established library is the road to success for most. (Personally, I use C with a library that I coded almost 20 years ago for most AGIs)

Doing it the ‘right way’ may seem more effort that it is worth, but the experience will open more doors for you. You may decide that writing most of your application as an AGI (or a series of AGIs) and just using dialplan for the ‘glue’ to hold it all together makes more sense.

Writing an application as an AGI has many advantages.

If you were to observe the same request issued by a ‘battle tested’ library you would see that Asterisk wants double quotes surrounding the value instead of single quotes. Personally, I would have coded it to accept both :upside_down_face:

Just for clarification, this topic should be named “How to use SET VARIABLE when the value has spaces” because you can have spaces in the variable’s name if you double quote it – but I’d advise against it :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.