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

Re: Request for enhancement

Expand Messages
  • Olivier Zendra
    [Since this message is of interest to many SmallEiffel users, I ve taken the liberty to also send it to the SmallEiffel mailing-list smalleiffel@loria.fr] ...
    Message 1 of 3 , Mar 1, 1999
    • 0 Attachment
      [Since this message is of interest to many SmallEiffel users, I've taken
      the liberty to also send it to the SmallEiffel mailing-list
      smalleiffel@...]

      Paul Johnson +44 1245 242244 wrote :
      >
      > We are making good progress with the SmallEiffel release of GRAPE. It
      > basically works, but I'm trying to do some tidying up in preparation for the
      > release.
      >
      > One thing I want to add is a "loadpath.se" file for Grape which is
      > location-independent. To this end it would be very useful to have environment
      > variable expansion built into the loadpath mechanism. Then the loadpath.se
      > file for grape could contain
      >
      > $GRAPE\win32\source\e-code\windows\
      >
      > instead of
      >
      > d:\eiffel\grape\win32\source\e-code\windows\
      >
      [patch to system.se deleted]
      >
      > Could you let me know if you plan on including this in the next beta? If so
      > then we will build it into our GRAPE distribution.

      Yes, we think accessing environment variables this way is a good idea.
      We'll integrate such a mechanism in our next release.

      We just have to make sure the notation to access an environment variable
      can't be mistaken with a directory name, whatever the platform. We in
      the SmallEiffel team thus tend to favor a ${VARIABLE} notation, instead
      of simply $VARIABLE, because we feel this should be safer, but this
      might be overkill. Is anybody aware of any problem which could arise
      with the $VARIABLE (or ${VARIABLE}) notation ?

      Thanks,

      --
      Olivier ZENDRA E-mail: zendra@...
      LORIA - NANCY - FRANCE http://SmallEiffel.loria.fr
    • Joachim Durchholz
      ... $VARIABLE is not a problem per se, but if file or directory names contain spaces the result might no more parse in an unambiguous way. Also, $VARIABLE will
      Message 2 of 3 , Mar 1, 1999
      • 0 Attachment
        Olivier Zendra wrote:
        >
        > We just have to make sure the notation to access an environment
        > variable can't be mistaken with a directory name, whatever the
        > platform. We in the SmallEiffel team thus tend to favor a ${VARIABLE}
        > notation, instead of simply $VARIABLE, because we feel this should be
        > safer, but this might be overkill. Is anybody aware of any problem
        > which could arise with the $VARIABLE (or ${VARIABLE}) notation ?

        $VARIABLE is not a problem per se, but if file or directory names
        contain spaces the result might no more parse in an unambiguous way.

        Also, $VARIABLE will create problems if you want to append another
        string to the substitution, like in $VARIABLEblah. It is much less
        likely that $(VARIABLE) can be misunderstood.

        Finally, Unix 'make' and company all use a $(VARIABLE) syntax, so I
        guess this one turned out to be better in whatever other ways. (And it
        is generally a good to have a terminator for every syntactic construct
        if there is a possibility that the syntax is extended later.)

        Regards,
        Joachim
        --
        Please don't send unsolicited ads.
      • Darren Hiebert
        ... Why cannot both $VARIABLE and ${VARIABLE} be supported, as they are in Unix shells? The braces are generally used to handle the $VARIABLEblah situation you
        Message 3 of 3 , Mar 2, 1999
        • 0 Attachment
          > Olivier Zendra wrote:
          > >
          > > We just have to make sure the notation to access an environment
          > > variable can't be mistaken with a directory name, whatever the
          > > platform. We in the SmallEiffel team thus tend to favor a ${VARIABLE}
          > > notation, instead of simply $VARIABLE, because we feel this should be
          > > safer, but this might be overkill. Is anybody aware of any problem
          > > which could arise with the $VARIABLE (or ${VARIABLE}) notation ?
          >
          > $VARIABLE is not a problem per se, but if file or directory names
          > contain spaces the result might no more parse in an unambiguous way.
          >
          > Also, $VARIABLE will create problems if you want to append another
          > string to the substitution, like in $VARIABLEblah. It is much less
          > likely that $(VARIABLE) can be misunderstood.

          Why cannot both $VARIABLE and ${VARIABLE} be supported, as they are
          in Unix shells? The braces are generally used to handle the
          $VARIABLEblah situation you cite.

          --
          Darren Hiebert <darren@...>
          http://darren.hiebert.com
        Your message has been successfully submitted and would be delivered to recipients shortly.