I have a specific proprietary application, which is dual use, running "account.exe" in a CGI context (eg from inside a web server) will make account.exe output a HTML page and such. Running "account.exe" outside of CGI context causes account.exe to enable certain command line functions.
Now to the question:
I want to run account.exe outside the CGI context in perl. Have tried with system(1, "command"); have tried with system("start command"), tried with a BAT wrapper that clears (SET VARIABLE=) every enviroment variable that has with CGI to do, but still account.exe "detects" that its run by a web server and outputs its HTML.
How can I run a windows command in a CGI script in perl (using strawberry perl) and making it impossible for the "account.exe" application to detect that the execution originally came from a web server?
There are many ways how account.exe could possibly detect how it was run.
Environment variables is one way; it seems you have already ruled that one out.
Normally processes can see who is their parent and their parent, so that could be other way.
So either you can do a lot of testing until you finally fool the specific technique that the process is using, or you might want to try sandboxing to gain more control on what the process can or cannot see (or do).
Related
I am working on an application where we are using xtermjs and node-pty inside of an electron application. We are adding a terminal to our application and would like to add some custom commands that are used in the terminal that are related to our application.
What are some options for adding these commands?
We want them installed with the application.
They don't have to be useable inside an 'external' terminal, but it is ok if they are. By external, i mean your normal terminal. Not our xterm & node-pty implementation.
And we want them to behave the same as other normal unix commands. Where you can pipe with other commands && them together and stuff.
I have played around with intercepting commands between xterm and node-pty and that was a disaster. I am now considering, just writing bash scripts for the commands and having the installer manage putting them where they need to be so they can be used.
Just wondering what my options are, thanks.
You can simply put all your executables in a directory that you add to your PATH when you invoke the shell in your terminal emulator.
The commands will be available to the user like any others in any construct that accepts commands, regardless of the user's shell or shell version (i.e. it'll work equally well in bash, zsh and fish).
If you need the commands to coordinate with your terminal emulator (e.g. if you want to process the command in JS in your Node.js process), you can arrange that via a second environment variable containing e.g. a host/port to connect to.
I am working on a project, where I need to execute multiple unix script from PHP environment. Could this be possible to open a single unix shell and execute all the unix scripts.
Currently im using shell_exec for each of the scripts execution. This makes the application slow, as each time shell_exec,a new shell is being opened and the script is executed.
Thanks in Advance,
No, the underlying shell is not accessible.
You could try few things:
Optimise the scripts so you have to do fewer execs. Pipe them or something like that
I am not sure if it will work but you should be able to start a bash process and send commands to it (see proc_open). This way you could be able to manually and reuse the shell. But I imagine it will be a nightmare, especially in parsing the responses from the scripts (if you need that).
We have an application that we have built as a bundle and we want to launch it from another process.
How should we do it?
From what I understand we can use openUrls(), openFile() or execve()
but I don't know which one better suits us.
Thanks
Since you're talking about an application, you don't want to go through the file association mechanisms. They're for opening documents, images etc. with an appropriate application. Since you don't seem to be sure what to ask, I'd say keep it simple:
The exec* family launches an executable directly. But note that it replaces the launching process with the launched application. Your launcher will stop executing at that point. If you want the launcher to continue to run, you want to use something that launches a subprocess. The low-level way is fork/vfork followed by exec, but it's far simpler to launch your app with system, which takes care of all that behind the scenes. (Assuming there are no security concerns about users on the other side of the world injecting execution paths).
If the launcher does not terminate as soon as it launches your app, you'll want to think about whether it "blocks" until the launched application terminates, or whether it launches the app asynchronously-- so that they then run in parallel. The launcher might also "wait" for the return value of the app, to check whether it succeeded and maybe do something afterwards. There are ways to do all that, but since we don't know what you need, I won't go into details.
In short: If the only job of your launcher is to start your app, use execl. If your launcher needs to do more, use system. If neither one quite fits your needs, you'll need to provide more information-- starting with the language your launcher is written in.
PS. Both of these have the advantage of generality and portability. They work for GUI and commandline applications, and they'll work on any Unix-like system, and to some extent on Windows. There's no need to lock yourself into Cocoa for something so simple.
If you're using Cocoa, you can use NSWorkspace's -launchApplication:.
From OSX documentation on NSWorkspaces:
openFile: Opens the specified file specified using the default application associated with its type.
openURL: Opens the location at the specified URL.
With url you can open also file on ftp, or http for example.
I have a GUI Ruby tool that needs to spawn a child command-line process, for example ping. If i do this on Windows, the console window will appear and dissapear for console process, that is very annoying. Is it possible to start a process from GUI Ruby script with no console window visible? If i use backtick operator or Kernel#system, the console window will appear, see example below:
require 'Tk'
require 'thread'
Thread.new { `ping 8.8.8.8` }
TkRoot.new.mainloop
The issue is that every executable on Windows is defined to be either a GUI executable or a Console executable (well, there's more detail than that but it doesn't matter here) at the time it is built. The executable that's running your Ruby script is a GUI executable (it also happens to use Tk to actually build a GUI, even if only a very simple one in your screenshot) and the ping executable is a Console executable. If a GUI executable starts a Console executable, a console is automatically created to run the executable in; you can't change this.
Of course, the picture is more complex than that. That's because a console application can actually work with the GUI (it just needs to do the right API calls) and you can use a whole catalogue of tricks to cause the console window to stay out of the way (such as starting ping through an appropriately-configured shortcut file) but such things are rather awkward. The easiest way is to have the console window be there the whole time by making Ruby itself be a console app (through naming your script with the .rb suffix, not .rbw). Yes, it doesn't really get rid of the problem, but it stops any annoying flashing.
If you were using ping as the purpose of your app (i.e., to find out if services were up) then I'd as whether it is possible/advisable to switch to writing the checking code directly in Ruby by connecting to the service instead of pinging it, as ping just measures whether the target OS kernel is alive, and not the service executable. This is a fine distinction, but I've seen machines get into a state where no executables were running but the machine was still responding to pings; this was very strange and can totally break your mental abstractions but can happen. But since you're only using ping as an example, I think you can just focus on the (rather problematic) console handling. Still, if you can do it without running a subprocess then definitely choose that method (on Windows; if you were on any sort of Unix you wouldn't have this problem at all).
It is indeed possible to spawn processes with Ruby. Here is a couple of ways to do it. I am not sure what you mean with
the console window will appear and dissapear for console process
but I think the best way for you to do it is to simply grab out and err and show it to your user in your own window. If you want the native windows console to appear wou probably need to something fancy with windows scripting.
One way to keep a spawned console alive is to have it run a batch file with a PAUSE command at the end:
rungping.bat:
ping %1
pause
exit
In your ruby file:
Thread.new {`start runping.bat 8.8.8.8`}
I am porting an application which runs as a background service in windows at startup, we are porting the application to linux(SUSE Enterprise server), I'am completely new to linux. Can somebody help me on how to proceed with this. Like
Should I build the linux executable
After builiding the binary, what changes should I make to linux startup files to run this executable
How my service can register call back function to modify or change or send commands to my service while it is running
Yes, you should build a Linux binary. You may want to rephrase your question since I doubt this is the answer you want :-)
You should generally create what is known as an "init" file, which lives in /etc/init.d. Novell has a guide online which you can use to author the file. Note that while the init file is common, the exact method of letting the operating system use it varies depending on the distribution.
This is going to be a marked change for you. If you are doing simple actions such as re-loading a configuration file, you can use the signals functionality, especially the SIGHUP/HUP signal which is generally used for this purpose. If you require extended communication with your daemon, you can use a UNIX domain socket (think of it as a named pipe) or a network socket.
Another task you are going to need to accomplish is to daemonize your application. Generally this is done by first fork()ing your process, then redirecting the stdin/stdout pipes in the child. There are more details which can be answered by reading this document
See how-to-migrate-a-net-windows-service-application-to-linux-using-mono.
Under Linux, deamons are simple background processes. No special control methods (e.g start(), stop()) are used as in Windows. Build your service as a simple (console) application, and run it in the background. You can use a tool like daemonize to run a program as a Unix daemon.