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

Re: [linuxham] Re: Macro problem

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