This is a reminder, this bug should be known as CYII6H4U95:
in one application we are using the lotusscript “shell” command to issue a operating system command.
This still does not work in Beta 2. If you are creating an agent with just on line
r = shell(“/usr/bin/unzip”)
you get “illegal function call”.
On the other hand, if you use @command([Execute]; “/usr/bin/unzip”) it spawns a terminal printing the help of the unzip program.
Subject: Information from Dev
Hi Julian,
This issue is no currently in plan to fix for 8.5 due to the fact that a workaround exists for it and there are other higher priority issues that we’re focusing on.
A few questions when assessing this - are there limitations to the workaround or reasons why the workaround is not sufficient? This additional information will help us to prioritize this work alongside the other bugs that we need to fix prior to shipping 8.5.
Thank you,
Sarah
Subject: Is this Mac only? What’s the workaround? (nt)
Subject: Workaround
The workaround is to use @command([Execute]; “/usr/bin/unzip”)
Subject: Thanks…
Is this Mac client only? More specifically, are server-run LS agents susceptible to this too?
Subject: Mac client only <>
Subject: how should this workaround work with parameters?
I don’t just to execute “unzip” without parameters, there is no point in that…I need to execute “unzip -d file.zip somedir/someotherdir” - as far as I tested I cannot do this with the @command.
Subject: Try putting the arguments as the 3rd arg to @command([Exeucute]
Example (tested only on windows): @Command([Execute]; “zip”; “c:\foo.zip c:\foo.TXT”) - creates foo.zip in root of c:
Subject: sorry, does not work on the Mac - workaround does NOT work
I tested the following:
@command([Execute]; “/usr/bin/unzip”; “/tmp/test.zip -d /tmp”)
but it does not work, the parameter is not passed to the unzip program. I only see a terminal window with the help text of unzip, that means that unzip was called without any parameter.
So this is not a workaround on the Mac, sorry.