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

Re: [linuxham] Macro problem

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.