lc shell and command line
Mike Bonner
I'm working on an lcshell script (as in a script that mimics a shell like
bash) and .. well the simple stuff is simple as you might guess. Its easy
enough to set a prompt based on current directory, loop and read stdin for
command lines, have it execute commands internal to the script, or execute
a shell for external commands as long as they're simple. Currently working
on re-creating the functionality of cd command. However, before I proceed
too far with this ugly hack it has become apparent that I need better
methods of parsing.
I'm hoping to include pipes, redirects, etc. Basically I am hoping to make
a fully functional interactive lcshell similar to perlsh.
Can anyone suggest reading materials, tutorials, examples of this type of
parsing that are basic enough to get me started down a better path than
the spaghetti code i'm smooshing together so far? (a mixture of switch
blocks, ifs, and 'best guesses')
Also, there was a post here about lc and the command line, and being able
to execute scripts directly. On linux and mac at least, scripts can use the
#! method to locate its executable, so lcserver works great for this.
In my case lcserver is located in /usr/lib/cgi-bin/livecode-server
so putting the following line first in an lc script will cause it to
execute.
#!/usr/lib/cgi-bin/livecode-server
<?lc
your script here
?>
The only negative is lc doesn't know to NOT print the # line. (part of the
reason i'm working towards an lcshell type script, start it up, then
execute what you want.)
Don't forget to set the file to executable of course.
_______________________________________________
use-livecode mailing list
use-li...@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Peter Alcibiades
pwd in a terminal does:
:~/ runrev 4.5/livecode-4.5.2$
cd ..
:~/ runrev 4.5$
pwd
runrev 4.5$
If you do the exact same things using put shell("...."), this doesn't work.
In particular,
put shell("pwd")
does indeed return the working directory, but
put shell("cd ..")
does not work at all. Why not? Probably an obvious reason - is it
something to do with escaping characters?
Peter
--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/lc-shell-and-command-line-tp4036681p4038742.html
Sent from the Revolution - User mailing list archive at Nabble.com.
Bernard Devlin
There is going to be no state maintained between different calls of
shell(). Thus, changing to a directory in one calls is not (IMO)
going to be maintained on a subsequent call of shel|(). Concatenating
commands (as I did above using the semi-collon), will mean they run in
the same invocation.
If you use 'cd' inside a shell such as Tclsh, it will maintain the
state of the change in directory. But even in something like Tclsh,
there are peculiarities around file globbing etc.
I guess you could try 'open process' and then 'talk' to the shell
opened that way. Although it's not clear to me that both of you are
trying to do the same thing. It looks like the OP may be planning to
use LiveCode as a general purpose shell-scripting language. I'm not
sure that is possible any more. The way he is invoking it is rather
like using PHP as a general purpose shell-scripting language.
Bernard
On Mon, Nov 14, 2011 at 8:12 AM, Peter Alcibiades
<palcibia...@yahoo.co.uk> wrote:
> I'm having trouble with the livecode shell and cd command also.
>
> pwd in a terminal does:
>
> :~/ runrev 4.5/livecode-4.5.2$
>
> cd ..
>
> :~/ runrev 4.5$
>
> pwd
>
> runrev 4.5$
>
> If you do the exact same things using put shell("...."), this doesn't work.
> In particular,
>
> put shell("pwd")
>
> does indeed return the working directory, but
>
> put shell("cd ..")
>
> does not work at all. Why not? Probably an obvious reason - is it
> something to do with escaping characters?
>
> Peter
_______________________________________________
Peter Alcibiades
would you get the shell to interact, like if you do su and want to get the
password in, and then run a script that requires root password? Or maybe
all that has to be done in shell?
Peter
--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/lc-shell-and-command-line-tp4036681p4039639.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
Mike Bonner
So you could do shell("command 1; command 2; command 3") and it would do
them in succession.
However rather than su to root its a much better idea to use sudo.
Beyond that, it might be easier to use open process so that you can open a
persistant connection to a shell. Something like : 'open process
"/bin/bash" for update'. Haven't done it, so you'd have to determine the
steps require to get your job done. It would allow you to send send
passwords and run scripts in a persistent environment this way.
as for using cd in a shell() call, its much easier to just set the
defaultfolder then any following shells will execute from the context you
set.
Bernard Devlin
configure some username, such that said the logged-in user does not
need to enter a password in order to call 'sudo su - auser'. If you
look inside /etc/sudoers it should explain what is required to make
access to sudo passwordless for that user. You can limit within
sudoers which programs such a passwordless user can run.
Basically, by encoding passwords inside scripts you are circumventing
security policies.
If you are really determined that the password should be stored in a
script for some reason, then you may be able to get around unix
security by piping a password to some program or by reconfiguring the
tty (which is the component in unix that is prompting you for a
password) such that it would take the password as a form of input
other than from an interactive prompt. A few days ago I saw in a book
on shell scripting how to redirect tty, but I don't have it to hand
now, and can't remember the details.
Once you have your circumvention working from a command line
(terminal), you should be able to pass that circumvention to shell()
within a livecode script.
I know that I have had to various forms of programmatic backflips to
"work within" unix security policies. I would focus on the problem as
a unix command line problem first. Then take that solution within
LiveCode. If it can run from a .sh script, then you are most of the
way to your solution.
I would really research the issues around unix security and sudo, su,
ssh thoroughly to understand the implications of what you are doing,
and the potential holes you open up. If you are wishing to su to root
programmatically, then unix is going to try and stop you doing that.
Bernard
On Mon, Nov 14, 2011 at 2:31 PM, Peter Alcibiades
<palcibia...@yahoo.co.uk> wrote:
> Bernard, many thanks, yes, that works. Can I ask one more question, how then
> would you get the shell to interact, like if you do su and want to get the
> password in, and then run a script that requires root password? Or maybe
> all that has to be done in shell?
>
> Peter
_______________________________________________
Mike Bonner
this is dangerous)
sudo su < filewithpword.txt; command 1; command 2; etc 3
scary thing to do though.
Peter Alcibiades
the root password on each occasion, not to store it someplace which you're
quite right of course would be very unwise.
I think maybe livecode is not what I should be using for this, the right way
is probably to have a shell script launched from a launcher on the desktop.
Its a bit complicated because what is needed is to launch a first script
which then calls a second one and executes as root. My second problem with
livecode was how to call the shell in such a way as to have the user enter
the password and then carry on with the script.
Its not quite so user friendly if it is all done in a terminal window, but
it will work.
Peter
--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/lc-shell-and-command-line-tp4036681p4040142.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
Mike Bonner
whatever you need to it directly from livecode. I also seem to recall that
its possible to open a process with elevated privileges but I can't find
the info on that for some reason. If you can figure out that portion it
could save quite a bit of hassle. Open the script with elevated privs, user
is prompted for pword, voila'. I'll see if I can remember where the docs
are for elevated process opening stuffs.
J. Landman Gay
> My second problem with
> livecode was how to call the shell in such a way as to have the user enter
> the password and then carry on with the script.
I probably shouldn't post about something I know so little about, but...
If you know you will need a password, could you just ask for it
beforehand, store it in a variable, and then incorporate the variable
into your shell script? I seem to remember there's a way to pass
authenticaion along with the script itself, all at once...I think.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Mike Bonner
as an elevated process, then writes to it and reads from it. Should be
possible to run a pre-made shell script too.
Yep, just tried it works fine. Notice the "whoami" command that is written,
it confirms that using open elevated process does indeed = root.
on mouseUp
put "/bin/bash" into tProcess
open elevated process tProcess for text update -- opens a shell with
elevated privs
-- writes commands to the shell. Here I change owner of a file to root,
--then later list it in field 1 as proof that it was done
write "chown root test.fil;ls -l test.fil" & return to process tProcess
-- makes sure there was time to complete the command before reading
wait 15 milliseconds
--this does just what it says
read from process tProcess until empty
put it & return into field 1
-- another check. Should show root as who I am.
write "whoami" & return to process tProcess
wait 15 milliseconds
-- get the results
read from process tProcess until empty
put it & return after field 1
close process tProcess
end mouseUp
Mark Wieder
Monday, November 14, 2011, 12:16:39 PM, you wrote:
> open elevated process seems to work ok. The following handler, opens bash
> as an elevated process, then writes to it and reads from it. Should be
> possible to run a pre-made shell script too.
That's a nice script. Unfortunately opening elevated processes doesn't
always work, as for instance on Fedora Core, where for some reason
that got deprecated by around version 9.
--
-Mark Wieder
mwi...@ahsoftware.net
Mike Bonner
well if at all.
Hmm, would calling login directly work? Probably not, as on many systems
root login is not allowed. If it were allowed, then the same basic idea
works. open process login then do the magic stuff, then exit out.
Also looked at suid ideas but couldn't make a suid script do root level
stuff no matter what I tried.
Makes me wish for a less fragmented linux. Oh well, open elevated is
working for me on ubuntu. Wish I had things that needed to be done that way!
Mark Wieder
Monday, November 14, 2011, 2:06:34 PM, you wrote:
> Hmm, would calling login directly work? Probably not, as on many systems
> root login is not allowed. If it were allowed, then the same basic idea
> works. open process login then do the magic stuff, then exit out.
It's not allowed, or at least made hard to get to, for good reason.
Nonetheless, the lack of gksu sucks.
Mark Schonewille
set the hideConsoleWindows to true
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553
Become our partner in sales http://qery.us/1bq Start selling Color Converter today. 20% commission!
On 18 nov 2011, at 17:27, John Brozycki wrote:
> Regarding shell commands and LiveCode....
>
> I've noticed that under OS X, invocation of a shell command is silent. But under Windows, you see a CMD window quickly pop up and disappear. I haven't found any options to prevent the shell command popping up under Windows, but wondered if anyone knew of a way to prevent it from happening.
>
> Thanks,
> John
Mike Bonner
will do what you wish.
On Fri, Nov 18, 2011 at 9:27 AM, John Brozycki <jo...@hvc.rr.com> wrote:
> Regarding shell commands and LiveCode....
>
> I've noticed that under OS X, invocation of a shell command is silent.
> But under Windows, you see a CMD window quickly pop up and disappear. I
> haven't found any options to prevent the shell command popping up under
> Windows, but wondered if anyone knew of a way to prevent it from happening.
>
> Thanks,
> John
>
John Brozycki
I've noticed that under OS X, invocation of a shell command is silent. But under Windows, you see a CMD window quickly pop up and disappear. I haven't found any options to prevent the shell command popping up under Windows, but wondered if anyone knew of a way to prevent it from happening.
Thanks,
John
On Nov 14, 2011, at 3:12 AM, Peter Alcibiades wrote:
Andre Garzia
As far as I know, you can't ask for the user password and pass it to a
shell call with clever use of pipes. That is not how sudo works, you can't:
cat password.txt | sudo cd ..
or
sudo cd .. < password.txt
The only way I found to script sudo calls is by using expect (
http://www.nist.gov/el/msid/expect.cfm ). Expect is a tool to automate
interactive console applications. You can craft an expect script that call
sudo and whatever else you want to do and call that script with shell().
=)
Roger Eller
> As far as I know, you can't ask for the user password and pass it to a
> shell call with clever use of pipes. That is not how sudo works, you can't:
>
> cat password.txt | sudo cd .. or sudo cd .. < password.txt
>
>
How about this method?
shell("pw=" & tPassword & "; echo $pw | sudo -S command")
SOURCE:
http://www.mail-archive.com/use-rev...@lists.runrev.com/msg137100.html
~Roger
Andre Garzia
Good finding. I gave the same comment as before lol... it appears that this
solution works, I haven't tested it.
Cheers
andre
--
http://www.andregarzia.com -- All We Do Is Code.
http://fon.nu -- minimalist url shortening service.
Roger Eller
> Roger,
>
> Good finding.
>
> Cheers
> andre
>
>
I keep the classic Revolution archive, as well as the new LiveCode archive
links handy for searching. There's lots of good stuff in both. It's too
bad the Developer List is private, and therefore not searchable.
http://www.mail-archive.com/use-rev...@lists.runrev.com
http://www.mail-archive.com/use-li...@lists.runrev.com
Peter Alcibiades
Roger Eller wrote:
>
> How about this method?
>
> shell("pw=" & tPassword & "; echo $pw | sudo -S command")
>
> SOURCE:
>
> ~Roger
>
Yes very neat, thanks. My problem was a bit different but maybe this can be
used. The real problem is that its a naive user in a remote location. So
without going over, modifying the sudo file isn't a possibility. A number
of lessons, one maybe being that remote maintenance would have been a
sensible thing to think about. Save a lot of time and trouble. Another
being, before you leave, make sure the full series of things the user wants
to do with the file has been tested. In the present case the files are
being generated OK, but with root ownership....
Its because of a workaround to make a scanner work. It does work, its just
the files it generates are owned by root....
--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/lc-shell-and-command-line-tp4036681p4085842.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________