Stats

  • Locked Locked
  • Replies 10
  • Subscribers 143
  • Views 20299
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How do you set a SKILL variable value to a shell evaluation?

jaleco

Using v5141, I am trying to set a SKILL variable value to be the result of a shell evaluation (which should return a text string). 

The shell operation is on a file generated during the Virtuoso session, otherwise it could be set in the .cdsinit or shell prior to running Virtuoso.

For example in Virtuoso I have just generated a log file:

myvar=system("grep myword mylogfile")

The system (or shell) command will write the text string to stdout of the shell, but puts the return value of the system() process into the SKILL variable.

While the shell will display the result of the grep operation (eg "myword"), the CIW gets a process return value, not the result of the grep.

printf("%L" myvar) ==> 0

I have tried using setShellEnvVar() to assign the variable to be in the shell and then reading it in.

setShellEnvVar("myvar=`grep myword mylogfile`")

But getShellEnvVar() returns the literal unevaluated string, not the shell evaluation.

getShellEnvVar("myvar") ==> "`grep myword mylogfile`"

How do you assign a SKILL variable value to the the string result of a shell operation like grep?

  • Hi,

    The return value of "system" function says whether the command ran successfully or not. So you may get values like 0 or 127 (for failed runs).

    The second method you are trying needs some modification. I'm not sure if it works.
    system("setenv myvar `grey myword mylogfile`")
    getShellEnvVar("myvar")

    One more way is to write to a file and read it back in skill using infile.

    -Ramakrishnan
  • Thanks Ramakrishnan,
    On the use of the system|shell() commands, understood, just illustrating how the shell will evaluate a command, but the evaluation does not get passed back to the SKILL variable.

    Regarding system("setenv...."), I don't see how this differs from setShellEnvVar()...
    I did try it however, and the "setenv" command is not recognized by the shell.

    Also understood that the file could be parsed in SKILL, but I was looking for a way to execute shell commands and have their evaluation get passed back to a SKILL variable. I'm actually using a more complicated string of commands to the shell than just grep, but could look into figuring out if the SKILL text parsing commands could do the same thing as the unix commands. File editing in SKILL didn't seem to be the right approach initially.
  • You would need to run something like ipcBeginProcess() to be able to read back strings from external programs and shell commands. In this case do you need to see the grep match or just know the return value? When you are invoking shell(), system() etc. the command is executed as a child of the current process which completes and exits, so even if it were able to set an environment variable that information is lost when the shell command completes. My guess is that you would need to use ipcBeginProcess().
    I hope this helps.

    Best regards,
    Lawrence.
  • Yes, file processing or editing is not really a strong suit of SKILL; Perl, Tcl, Python etc. are probably better choices. If you are just doing simple matching/regular expressions then I would recommend pcreCompile/pcreExecute/pcreSubstitute/pcreReplace as good places to start. But ah, you're in 5141, I think these came later. You might be stuck with rexMatchp()...
  • Thanks Lawrence,
    Interesting. I thought the child process continued, not exited with the result of the system() command. I was thinking of the child process like an xterm though, not as a command.

    Yes, I actually have tried the ipc*Process() commands, but they also return success or failure values, like system().
    My documentation on ipcReadProcess() claims that it returns t_data from the child process' stdout, or nil, but the only t_data return value I have gotten is "t".
    ipcReadProcess(ipcBeginProcess("`grep myword mylogfile`")) ==> t

  • You need to give it time to get started and for the communication 'channel' to be open. Something like this:

     cid = ipcBeginProcess("grep myword mylogfile") ;; no backquotes
 ipcWaitForProcess(cid [optional timeout])
 ipcReadProcess(cid) => "matching myword string\n"

    Think of the ipcXX commands as more of a flow than single line do-it-all-in-one-go commands.
    Regards,
    Lawrence.

  • Ahh - wait for it....that works better. Thanks!
  • For other users....used in succession, the final ipcReadProcess(cid) returns a string looking something as described above.
    In my case :
    "sh: myword: command not found\n"

    Setting this to a SKILL variable and getting to the core of the shell evaluation looked like:
    ipcret=ipcReadProcess(cid)
    mySkillvar=buildstring(cddadr(readstring(ipcret)))

    such that...
    printf("%s" mySkillvar) ==> myword
  • Remove the backquotes, that's why you are getting the "sh: myword: command not found" - with the backquotes you're asking the shell to execute the result of "grep myword mylogfile" rather than just the grep command on its own.

    Best regards,
    Lawrence.
  • Sorry, I missed that part of your sample code....specifically called out.
    One last tip for others - remove the trailing newline of the string value with a pipe to transliterate -
    grep .....| tr -d '\n'
    and ipcReadProcess(cid) should return ==> "myword" instead of "myword\n"

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.