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.
Related
Inside a batch file, I need to run an executable in a maximized terminal.
I've found saveral answers, all suggesting the use of start /max.
However, when using start, the terminal automatically shuts down upon completion.
So I want to use call instead, but I cannot find the equivalent syntax.
I've also tried executing mode cols=200 lines=300 before executing call, but it just opened a large terminal, not setup in full-screen, which made it even less convenient than a small terminal.
I've been learning shell script on my Mac recently. Take an application like Atlassian's SourceTree as an example. My understanding is that it's just a GUI for git commands, which can be executed through command line. Pressing a button just triggers a corresponding git command, which is effectively run through the command line behind the scenes. If that is the case, do all applications that have a GUI function this way? Are all applications essentially just running their commands through the machine's shell script? And if so, are the underlying commands that are being used publicly available, offering an API of sorts for any application?
This is more complex than that.
Many applications only have a GUI (e.g., Safari), many others only have a CLI (e.g., find).
When a GUI app and a CLI app perform the same function, they may communicate with each other or they may not:
As you point out a GUI application can run a CLI command behind the scene (with system() or popen() for instance)
An alternative is that both applications use the same underlying library
Or no code is shared at all (think of ls vs. Finder on Mac)
Finally on Mac some GUI apps can be controlled with Applescript language, which is available through osascript command. In other words, you can control iTunes with a bash script.
Definitely, not all applications behave that way. In fact, from my experience, I'd say that there are few applications that follow that. Most applications perform their own operations relying directly on the OS platform and functionalities, instead of executing shell commands which, in addition, are hard (and most of the time impossible) to port between OSs.
The centerpiece of Microsoft Windows' UI is called Windows Shell. Classically it was Windows Explorer, but I understand that in Windows 8 it's something else ("Immersive Shell"?) Anyways, it's possible to replace the shell with something else - Windows itself supports Command Prompt as the shell out of the box, but there are several 3rd party shells available as well, and have been for more than two decades.
At the same time there's something called "The Shell API". It includes a lot of functions, interfaces, registry keys, etc. which are designed to allow a program to interact with the Shell. You can, for instance, show the Windows File-copy dialog from your own program; navigate the Shell Namespace, write an extension for the Shell; etc.
And this confuses me. If the Shell can be replaced, doesn't that mean that the Shell API is replaced with it? Won't installing a different shell break all the applications that use the Shell API? Even more - things like the Shell Namespace are essential to Windows as such; I can't imagine replacing it with something else.
Or is it so the Shell API is separate from the Shell itself, and every replaceable Shell must implement a specific set of interfaces (and adhere to mandatory conventions like the Shell Namespace) in order to work?
It is separate. The shell is Explorer.exe. The shell api is implemented in DLLs. So you can use them even if Explorer.exe isn't running.
Of course don't expect shell extensions to work in a replacement shell.
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).
Hey there, I'm building a remote shell server that interfaces between a text-only client and a virtual shell.
It works perfectly when using regular shell commands, but the first thing that people try after that is vim, which promptly drives my server crazy and can't even be closed remotely.
Is there any way to detect ncurses based programs and prevent them from running in my special shell?
(the server is ruby, but any system command will do)
You can declare the capabilities your shell has, by setting the TERM environment variable to the correct value. For instance, if your shell has the same capabilities as the vt100 terminal, export TERM to the correct value, and programs like vim will respect that.
To run vim in vt100-mode, try:
TERM=vt100 vim
You could also try:
export TERM=dumb
The trick is to find a terminal that corresponds to the capabilities of what you are creating. There is a lot to choose from. On my system (Arch Linux) this gives me a long list of choices:
find /usr/share/terminfo
You might be able to find a terminal specification that corresponds to what your program can handle.
Alternatively, you may want to consider implementing terminal emulation for ansi or vt100:
http://en.wikipedia.org/wiki/ANSI_escape_code
http://www.termsys.demon.co.uk/vtansi.htm
Best of luck!