Loading ...
Sorry, an error occurred while loading the content.

Macro problem

Expand Messages
  • tidalwaters
    I m trying to make some creative macros using the neat ability to write executable scripts and use them in fldigi. I ve read (over and over) the HELP files,
    Message 1 of 12 , Nov 30, 2012
    • 0 Attachment
      I'm trying to make some creative macros using the neat ability to write executable scripts and use them in fldigi. I've read (over and over) the HELP files, particularly on EXEC in http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html.

      I've set out to learn by following the example in the link above. I've made a macro key definition as follows:

      <EXEC>cat /home/username/.fldigi/scripts/foo</EXEC>
      <EXEC>cat foo</EXEC>
      <EXEC>echo $PATH</EXEC>
      <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
      <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>


      Now I run this macro and the Tx window prints:


      <MYCALL>

      /home/username/.fldigi/scripts:/usr/local/bin:/usr/bin:/bin:/usr/games
      my call is: wa4caw
      fldigi version is: 3.21.61


      The path has been modified to include ~/.fldigi/scripts as stated in the help file, however I still must include the full path in the macro def or else the file is not found. This is evidenced by the blank 2nd line in the macro return.

      For this test I have given the file foo 0777 permissions so that should not be the problem.

      And, even when given the full path to foo the macro returns "<MYCALL>" rather than the expansion of that macro tag which would be the callsign assigned to the variable FLDIGI_MY_CALL, which is echoed correctly by the 4th line of the macro def.

      I installed this version of fldigi from the package in debian unstable archives. Fldigi works just fine otherwise.

      I'm missing something pretty obvious or else it ain't working right. Any help or explanations would be appreciated. Thank you.

      Mac
      wa4caw
    • Bob Snyder
      ... Hi Mac, I m not really conversant with the macro, but I think the system is doing exactly what your macro is asking, which is to cat the file. In
      Message 2 of 12 , Nov 30, 2012
      • 0 Attachment
        On 11/30/2012 07:11 PM, tidalwaters wrote:
        > I'm trying to make some creative macros using the neat ability to write executable scripts and use them in fldigi. I've read (over and over) the HELP files, particularly on EXEC in http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html.
        >
        > I've set out to learn by following the example in the link above. I've made a macro key definition as follows:
        >
        > <EXEC>cat /home/username/.fldigi/scripts/foo</EXEC>
        > <EXEC>cat foo</EXEC>
        > <EXEC>echo $PATH</EXEC>
        > <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
        > <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>
        >
        >
        > Now I run this macro and the Tx window prints:
        >
        >
        > <MYCALL>
        >
        > /home/username/.fldigi/scripts:/usr/local/bin:/usr/bin:/bin:/usr/games
        > my call is: wa4caw
        > fldigi version is: 3.21.61
        >
        >
        > The path has been modified to include ~/.fldigi/scripts as stated in the help file, however I still must include the full path in the macro def or else the file is not found. This is evidenced by the blank 2nd line in the macro return.
        >
        > For this test I have given the file foo 0777 permissions so that should not be the problem.
        >
        > And, even when given the full path to foo the macro returns "<MYCALL>" rather than the expansion of that macro tag which would be the callsign assigned to the variable FLDIGI_MY_CALL, which is echoed correctly by the 4th line of the macro def.
        >
        > I installed this version of fldigi from the package in debian unstable archives. Fldigi works just fine otherwise.
        >
        > I'm missing something pretty obvious or else it ain't working right. Any help or explanations would be appreciated. Thank you.
        >
        > Mac
        > wa4caw

        Hi Mac,

        I'm not really conversant with the <EXEC> macro, but I think the system
        is doing exactly what your macro is asking, which is to cat the file. In
        other words you want to execute the file with <MYCALL> in it, but the
        macro is telling it to cat it, not execute it. It doesn't show anything
        for the second line because it isn't trying to execute the foo macro,
        just cat it, and the PATH variable is no help for that. Try again
        without the cat command, and without the path.

        Bob W6CP
      • Bob Snyder
        ... Hi again Mac, On second thought... My previous reply was a bit incomplete. Simply removing the cat commands isn t enough. What you need is an actual
        Message 3 of 12 , Nov 30, 2012
        • 0 Attachment
          On 11/30/2012 09:15 PM, Bob Snyder wrote:
          > On 11/30/2012 07:11 PM, tidalwaters wrote:
          >> I'm trying to make some creative macros using the neat ability to write executable scripts and use them in fldigi. I've read (over and over) the HELP files, particularly on EXEC in http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html.
          >>
          >> I've set out to learn by following the example in the link above. I've made a macro key definition as follows:
          >>
          >> <EXEC>cat /home/username/.fldigi/scripts/foo</EXEC>
          >> <EXEC>cat foo</EXEC>
          >> <EXEC>echo $PATH</EXEC>
          >> <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
          >> <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>
          >>
          >>
          >> Now I run this macro and the Tx window prints:
          >>
          >>
          >> <MYCALL>
          >>
          >> /home/username/.fldigi/scripts:/usr/local/bin:/usr/bin:/bin:/usr/games
          >> my call is: wa4caw
          >> fldigi version is: 3.21.61
          >>
          >>
          >> The path has been modified to include ~/.fldigi/scripts as stated in the help file, however I still must include the full path in the macro def or else the file is not found. This is evidenced by the blank 2nd line in the macro return.
          >>
          >> For this test I have given the file foo 0777 permissions so that should not be the problem.
          >>
          >> And, even when given the full path to foo the macro returns "<MYCALL>" rather than the expansion of that macro tag which would be the callsign assigned to the variable FLDIGI_MY_CALL, which is echoed correctly by the 4th line of the macro def.
          >>
          >> I installed this version of fldigi from the package in debian unstable archives. Fldigi works just fine otherwise.
          >>
          >> I'm missing something pretty obvious or else it ain't working right. Any help or explanations would be appreciated. Thank you.
          >>
          >> Mac
          >> wa4caw
          > Hi Mac,
          >
          > I'm not really conversant with the <EXEC> macro, but I think the system
          > is doing exactly what your macro is asking, which is to cat the file. In
          > other words you want to execute the file with <MYCALL> in it, but the
          > macro is telling it to cat it, not execute it. It doesn't show anything
          > for the second line because it isn't trying to execute the foo macro,
          > just cat it, and the PATH variable is no help for that. Try again
          > without the cat command, and without the path.
          >
          > Bob W6CP
          >

          Hi again Mac,

          On second thought...

          My previous reply was a bit incomplete. Simply removing the 'cat'
          commands isn't enough. What you need is an actual shell script that
          prints out "<MYCALL>". So change your foo script to this:

          #! /bin/bash
          echo \<MYCALL\>

          and your macro to this:

          <EXEC>foo</EXEC>
          <EXEC>echo $PATH</EXEC>
          <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
          <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>

          I've tested this and it appears to do what you want. The backslashes are
          needed because the angle brackets are apparently reserved for special
          use in a shell script.

          Bob W6CP
        • tidalwaters
          Bob, thank you for your comments. Maybe I don t understand the manual correctly. from the EXEC MACRO instruction page: Detection of existing scripts In
          Message 4 of 12 , Dec 1, 2012
          • 0 Attachment
            Bob, thank you for your comments. Maybe I don't understand the manual correctly.

            from the "EXEC MACRO" instruction page:

            Detection of existing scripts
            In anticipation of a collection of useful "fldigi scripts", the macro browser contains a macro line for each executable file found in the scripts directory.

            The EXEC macro allows the text that is read from the child process to be parsed for more fldigi macros. For example, try this macro:

            <EXEC>cat foo</EXEC>

            where foo is a file that contains:

            <MYCALL>


            I did exactly that and my understanding is that it should return the result of the macro tag <MYCALL> (which is wa4caw), not just return the the characters "<MYCALL>". I hope the developers will comment on this to explain or clarify the instructions. Maybe I'm misreading and expecting something different than their intent.

            Again, what does "The EXEC macro allows the text that is read from the child process to be parsed for more fldigi macros." mean and perhaps a different or more detailed example could be given. I'm not a programmer but I do have a decent laymans understanding of bash scripting and the published example is not working the way I expected by reading the manual. I am expecting the <MYCALL> in the file foo to be expanded into wa4caw and so far it's not happening that way.

            Surely someone else out there has tried the example given in the manual. What did you get??

            Thanks much

            Mac
            wa4caw




            --- In linuxham@yahoogroups.com, Bob Snyder <bob.snyder@...> wrote:
            >
            > On 11/30/2012 09:15 PM, Bob Snyder wrote:
            > > On 11/30/2012 07:11 PM, tidalwaters wrote:
            > >> I'm trying to make some creative macros using the neat ability to write executable scripts and use them in fldigi. I've read (over and over) the HELP files, particularly on EXEC in http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html.
            > >>
            > >> I've set out to learn by following the example in the link above. I've made a macro key definition as follows:
            > >>
            > >> <EXEC>cat /home/username/.fldigi/scripts/foo</EXEC>
            > >> <EXEC>cat foo</EXEC>
            > >> <EXEC>echo $PATH</EXEC>
            > >> <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
            > >> <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>
            > >>
            > >>
            > >> Now I run this macro and the Tx window prints:
            > >>
            > >>
            > >> <MYCALL>
            > >>
            > >> /home/username/.fldigi/scripts:/usr/local/bin:/usr/bin:/bin:/usr/games
            > >> my call is: wa4caw
            > >> fldigi version is: 3.21.61
            > >>
            > >>
            > >> The path has been modified to include ~/.fldigi/scripts as stated in the help file, however I still must include the full path in the macro def or else the file is not found. This is evidenced by the blank 2nd line in the macro return.
            > >>
            > >> For this test I have given the file foo 0777 permissions so that should not be the problem.
            > >>
            > >> And, even when given the full path to foo the macro returns "<MYCALL>" rather than the expansion of that macro tag which would be the callsign assigned to the variable FLDIGI_MY_CALL, which is echoed correctly by the 4th line of the macro def.
            > >>
            > >> I installed this version of fldigi from the package in debian unstable archives. Fldigi works just fine otherwise.
            > >>
            > >> I'm missing something pretty obvious or else it ain't working right. Any help or explanations would be appreciated. Thank you.
            > >>
            > >> Mac
            > >> wa4caw
            > > Hi Mac,
            > >
            > > I'm not really conversant with the <EXEC> macro, but I think the system
            > > is doing exactly what your macro is asking, which is to cat the file. In
            > > other words you want to execute the file with <MYCALL> in it, but the
            > > macro is telling it to cat it, not execute it. It doesn't show anything
            > > for the second line because it isn't trying to execute the foo macro,
            > > just cat it, and the PATH variable is no help for that. Try again
            > > without the cat command, and without the path.
            > >
            > > Bob W6CP
            > >
            >
            > Hi again Mac,
            >
            > On second thought...
            >
            > My previous reply was a bit incomplete. Simply removing the 'cat'
            > commands isn't enough. What you need is an actual shell script that
            > prints out "<MYCALL>". So change your foo script to this:
            >
            > #! /bin/bash
            > echo \<MYCALL\>
            >
            > and your macro to this:
            >
            > <EXEC>foo</EXEC>
            > <EXEC>echo $PATH</EXEC>
            > <EXEC>echo "my call is: $FLDIGI_MY_CALL"</EXEC>
            > <EXEC>echo "fldigi version is: $FLDIGI_VERSION"</EXEC>
            >
            > I've tested this and it appears to do what you want. The backslashes are
            > needed because the angle brackets are apparently reserved for special
            > use in a shell script.
            >
            > Bob W6CP
            >
          • Ed
            ... You need a file containing your call, not the macro tag. The above is misleading, but none the less you need a file or a perl scrpt. Ed W3NR
            Message 5 of 12 , Dec 1, 2012
            • 0 Attachment
              On 12/01/2012 10:04 AM, tidalwaters wrote:
              >
              >
              > Bob, thank you for your comments. Maybe I don't understand the
              > manual correctly.
              >
              > from the "EXEC MACRO" instruction page:
              >
              > Detection of existing scripts In anticipation of a collection of
              > useful "fldigi scripts", the macro browser contains a macro line for
              > each executable file found in the scripts directory.
              >
              > The EXEC macro allows the text that is read from the child process to
              > be parsed for more fldigi macros. For example, try this macro:
              >
              > <EXEC>cat foo</EXEC>
              >
              > where foo is a file that contains:
              >
              > <MYCALL>

              You need a file containing your call, not the macro tag. The above is
              misleading, but none the less you need a file or a perl scrpt.

              Ed W3NR
            • tidalwaters
              Thank you Ed, as always, for your learned comments. But..., if the instructions are misleading, can you give me a clarified example, instructions, etc. And,
              Message 6 of 12 , Dec 1, 2012
              • 0 Attachment
                Thank you Ed, as always, for your learned comments. But..., if the instructions are misleading, can you give me a clarified example, instructions, etc.

                And, if the macro tag is not expected to be expanded, what is the next section of the instructions talking about...

                "The <STOP> and <CONT> macros stop and resume the expansion of all <MACRO> strings. For example, <STOP><MYCALL><CONT><MYCALL> would only expand the second <MYCALL>. By wrapping the command output in this way we can be sure that no text will be expanded." Followed by an example bash script (noexp) whereby the <STOP> and <CONT> tags are used in the script.

                What exactly then is the meaning of "The EXEC macro allows the text that is read from the child process to be parsed for more fldigi macros."

                There is every reason here to believe that the author intended macros to be expanded in a script (or not if the noexp script is used). Was this available in an earlier release and now removed?? Are the instructions in need of rewriting/clarification/better examples ??

                Again, I have read these instruction many times in the past few days, I have tried many variations of scripts and macro key defs. If it will work I would like to understand it, if it simply is a feature that has been deleted then I'd appreciate knowing that also. Or, if it is a bug then it has been discovered. There's also the possibility that I'm reading way too much into it :)

                Specifically, what I would like to know if there is a way to have a script call one of the defined macro tags and have it respond just as if it had been called by the macro key def. Not printed to the Tx buffer, but function as if called normally.

                And, similarly is there a way to have some externally determined text applied as a macro tag parameter. For example, <FILE:filename> where filename comes from the output (or variable assignment) of a script. Or, <GOFREQ:freq> where freq comes from the script, etc.

                Thanks much,

                Mac
                wa4caw



                --- In linuxham@yahoogroups.com, Ed <autek@...> wrote:
                >
                > On 12/01/2012 10:04 AM, tidalwaters wrote:
                > >
                > >
                > > Bob, thank you for your comments. Maybe I don't understand the
                > > manual correctly.
                > >
                > > from the "EXEC MACRO" instruction page:
                > >
                > > Detection of existing scripts In anticipation of a collection of
                > > useful "fldigi scripts", the macro browser contains a macro line for
                > > each executable file found in the scripts directory.
                > >
                > > The EXEC macro allows the text that is read from the child process to
                > > be parsed for more fldigi macros. For example, try this macro:
                > >
                > > <EXEC>cat foo</EXEC>
                > >
                > > where foo is a file that contains:
                > >
                > > <MYCALL>
                >
                > You need a file containing your call, not the macro tag. The above is
                > misleading, but none the less you need a file or a perl scrpt.
                >
                > Ed W3NR
                >
              • Ed
                Mac, sorry for the big snip, but it was starting to get hard to follow. Plus a lot of users have restricted bandwidith. Reading the help file ::
                Message 7 of 12 , Dec 2, 2012
                • 0 Attachment
                  Mac, sorry for the big snip, but it was starting to get hard to follow.
                  Plus a lot of users have restricted bandwidith.

                  Reading the help file ::

                  http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html

                  Fldigi exports a set of variables to the child process and adds
                  ~/.fldigi/scripts to the PATH variable before running the shell code.
                  This is the directory location for all executable scripts and programs
                  which you might want to call from within the macro.

                  Notice it is saying either a *script or program*, located in /scripts.

                  Now read the next paragraph and follow Dave's example.

                  The next paragraph tells you that a *file* containing <MYCALL>.

                  Now in my /scripts I have a Perl script that calls my local NOAA wx station.

                  I have a macro in fldigi that executes the above.

                  <EXEC> getwx.pl</EXEC>.

                  From the above you can see that you cannot just put <MYCALL> in a EXEC
                  macro tag as it is not a file or script in the /script directory.

                  Ed W3NR
                • tidalwaters
                  Ed, thanks once again. No problem on the snip, I agree it needed it. Your explanation below is good, but it does not answer my question. I have scripts in
                  Message 8 of 12 , Dec 2, 2012
                  • 0 Attachment
                    Ed, thanks once again. No problem on the snip, I agree it needed it.

                    Your explanation below is good, but it does not answer my question. I have scripts in the directory that I can run using EXEC. BUT, they do not expand fldigi macros that appear in the script, they merely print the macro tag on the Tx buffer window. The 2 examples given in the instructions DO show expansion of the macro that is imbedded in the script. I guess I may be the first and only user to try this feature since no body else is responding here.

                    If the instructions are misleading or incomplete regarding the script "foo", then move down to the next example using the noexp script. Copy/Paste right from the instructions. When run exactly as the instructions show it does nothing except print "<STOP>" before the command and then print "<CONT>" after the command. It neither stops nor continues macro processing as is pretty clearly described in the instructions. I guess this feature is broken or has just never been fully implemented. Probably Dave is the only one that can answer that.

                    Since nobody else seems interested in this I will take a cold shower and move on to something else.

                    Thanks again.

                    Mac
                    wa4caw





                    --- In linuxham@yahoogroups.com, Ed <autek@...> wrote:
                    >
                    > Mac, sorry for the big snip, but it was starting to get hard to follow.
                    > Plus a lot of users have restricted bandwidith.
                    >
                    > Reading the help file ::
                    >
                    > http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html
                    >
                    > Fldigi exports a set of variables to the child process and adds
                    > ~/.fldigi/scripts to the PATH variable before running the shell code.
                    > This is the directory location for all executable scripts and programs
                    > which you might want to call from within the macro.
                    >
                    > Notice it is saying either a *script or program*, located in /scripts.
                    >
                    > Now read the next paragraph and follow Dave's example.
                    >
                    > The next paragraph tells you that a *file* containing <MYCALL>.
                    >
                    > Now in my /scripts I have a Perl script that calls my local NOAA wx station.
                    >
                    > I have a macro in fldigi that executes the above.
                    >
                    > <EXEC> getwx.pl</EXEC>.
                    >
                    > From the above you can see that you cannot just put <MYCALL> in a EXEC
                    > macro tag as it is not a file or script in the /script directory.
                    >
                    > Ed W3NR
                    >
                  • Larry Levesque
                    Excuse me for coming late in the game here. What OS are you are using? Larry Levesque KA1VGM Cheshire County EC NHARES
                    Message 9 of 12 , Dec 2, 2012
                    • 0 Attachment
                      Excuse me for coming late in the game here.

                      What OS are you are using?

                      Larry Levesque
                      KA1VGM
                      Cheshire County EC
                      NHARES


                      On Sun, Dec 2, 2012 at 9:47 AM, tidalwaters <lmcarthur@...> wrote:
                       



                      Ed, thanks once again. No problem on the snip, I agree it needed it.

                      Your explanation below is good, but it does not answer my question. I have scripts in the directory that I can run using EXEC. BUT, they do not expand fldigi macros that appear in the script, they merely print the macro tag on the Tx buffer window. The 2 examples given in the instructions DO show expansion of the macro that is imbedded in the script. I guess I may be the first and only user to try this feature since no body else is responding here.

                      If the instructions are misleading or incomplete regarding the script "foo", then move down to the next example using the noexp script. Copy/Paste right from the instructions. When run exactly as the instructions show it does nothing except print "<STOP>" before the command and then print "<CONT>" after the command. It neither stops nor continues macro processing as is pretty clearly described in the instructions. I guess this feature is broken or has just never been fully implemented. Probably Dave is the only one that can answer that.

                      Since nobody else seems interested in this I will take a cold shower and move on to something else.

                      Thanks again.

                      Mac
                      wa4caw

                      --- In linuxham@yahoogroups.com, Ed <autek@...> wrote:
                      >
                      > Mac, sorry for the big snip, but it was starting to get hard to follow.
                      > Plus a lot of users have restricted bandwidith.
                      >
                      > Reading the help file ::
                      >
                      > http://www.w1hkj.com/FldigiHelp-3.21/execmacro.html
                      >
                      > Fldigi exports a set of variables to the child process and adds
                      > ~/.fldigi/scripts to the PATH variable before running the shell code.
                      > This is the directory location for all executable scripts and programs
                      > which you might want to call from within the macro.
                      >
                      > Notice it is saying either a *script or program*, located in /scripts.
                      >
                      > Now read the next paragraph and follow Dave's example.
                      >
                      > The next paragraph tells you that a *file* containing <MYCALL>.
                      >
                      > Now in my /scripts I have a Perl script that calls my local NOAA wx station.
                      >
                      > I have a macro in fldigi that executes the above.
                      >
                      > <EXEC> getwx.pl</EXEC>.
                      >
                      > From the above you can see that you cannot just put <MYCALL> in a EXEC
                      > macro tag as it is not a file or script in the /script directory.
                      >
                      > Ed W3NR
                      >


                    • David
                      Use the following technique for your external EXEC script ============snip, the script (chmod a+x)========= #!/bin/bash echo -n Good morning all, de $1 n
                      Message 10 of 12 , Dec 2, 2012
                      • 0 Attachment
                        Use the following technique for your external "EXEC" script

                        ============snip, the script (chmod a+x)=========
                        #!/bin/bash

                        echo -n "Good morning all, de $1\n"
                        exit $?
                        ============snip=================================

                        ============snip, the macro definition===========
                        <EXEC>demo_script.sh $FLDIGI_MY_CALL</EXEC>
                        ============snip=================================

                        73, Dave
                      • David
                        Modify the file src/misc/macros.cxx as follows to restore the post EXEC macro text expansion: // remove all trailing end-of-lines while
                        Message 11 of 12 , Dec 2, 2012
                        • 0 Attachment
                          Modify the file src/misc/macros.cxx as follows to restore the post EXEC macro text expansion:

                          // remove all trailing end-of-lines
                          while (lnbuff[lnbuff.length()-1] == '\n')
                          lnbuff.erase(lnbuff.length()-1,1);

                          if (!lnbuff.empty()) {
                          // NEW LINE
                          lnbuff = m.expandMacro(lnbuff, false);
                          s.insert(i, lnbuff);
                          i += lnbuff.length();
                          } else
                          i++;

                          fclose(fp);
                          close(pfd[0]);

                          73, Dave, W1HKJ
                        • tidalwaters
                          Dave, thanks, now things are starting to make sense. Do you expect this will be included in future releases or remain a user mod? Mac wa4caw
                          Message 12 of 12 , Dec 3, 2012
                          • 0 Attachment
                            Dave, thanks, now things are starting to make sense. Do you expect this will be included in future releases or remain a user mod?

                            Mac
                            wa4caw


                            --- In linuxham@yahoogroups.com, "David" <w1hkj@...> wrote:
                            >
                            > Modify the file src/misc/macros.cxx as follows to restore the post EXEC macro text expansion:
                            >
                            > // remove all trailing end-of-lines
                            > while (lnbuff[lnbuff.length()-1] == '\n')
                            > lnbuff.erase(lnbuff.length()-1,1);
                            >
                            > if (!lnbuff.empty()) {
                            > // NEW LINE
                            > lnbuff = m.expandMacro(lnbuff, false);
                            > s.insert(i, lnbuff);
                            > i += lnbuff.length();
                            > } else
                            > i++;
                            >
                            > fclose(fp);
                            > close(pfd[0]);
                            >
                            > 73, Dave, W1HKJ
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.