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!
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.
In the past, I have used MATLAB sparingly from Linux machines at work, and I far and away preferred using the '-nodesktop' option. On all Unix-like machines I've worked on this option allows me to control STDIN and STOUT with relative ease, but on Windows(using Cygwin) this option spawns a new window and control is returned to the calling shell!
Basically, I would like to know if there is any way that I can force MATLAB to behave as it would on a Unix-like machine?
Thanks!
Short answer: You can not.
A longer answer can be found on their website.
-nodesktop behaves differently depending if you are on Windows vs
Linux or Mac. On Windows we provide a boring Command-Window only
interface that lacks the “bells and whistles” of the regular Command
Window or the full Desktop.
So you can use -nodesktop, but it pops up that annoying command line only window.
I have been reading how to use a shell inside EMACS, along the way I found the concept of Terminal, which is an abstraction for the old physical devices which interacted with the shell.
But, nowadays, I really can't understand which are the advantages regarding its use, so, can you please point me out a couple of situations or examples where one should use it instead of the shell in Emacs?
Running a term buffer is much closer to an actual terminal. Here are a few differences:
Shell mode provides very limited terminal emulation. Programs that take advantage of the terminal's full-screen capabilities (e.g. less, mtr, mutt, top) won't work properly. Terminal mode will generally handle these without any problem.
In shell mode, emacs provides tab completion. In terminal mode, the shell or command-line program provide it themselves.
Shell mode buffers the input and sends it to the process on newline. Terminal mode sends the characters to the running process immediately.
Shell mode works like a regular buffer with the usual emacs key bindings. Terminal mode doesn't intercept most control characters unless you explicitly put it into line mode.
The shell is like another emacs buffer, so the same keys work in it which work in other buffers. It is not true for the terminal.
You can launch the console programs that clear the screen like mc in terminal.
Physical terminals are long obsolete, but the terminal emulators which replaced them are pretty important, and I would presume that most shells outside of Emacs are run within one, so it's not such a mysterious concept to use one within Emacs too.
It's only tangential to your question, but The TTY demystified is an excellent article which you might find enlightening.
I don't know if this is a dumb question or not but again as my professor says if you have doubts then clear them . What is the difference between Linux text mode and windows command prompt (cmd). I know both windows and Linux are different Operating Systems but when you look at the commands, some of the commands are common For Example cd command.
Although superficially similar in some ways, the two command line interfaces have different lineages:
The Windows command prompt is based heavily on that of MS-DOS / PC-DOS, which in turn was based on the CP/M Console Command Processor. The CP/M CCP interface was itself based on an earlier operating system called RSTS.
The Linux shells trace their roots back to the original UNIX Thompson shell; the Thompson shell borrowed from the Multics shell (where the term "shell" originated).
Traces of these are still evident today - the DIR command in the Windows command prompt can be traced all the way back to the DIR command in RSTS, and similarly the ls command in GNU coreutils can be traced back to the Multics "list segments" command.
They're both based on the same idea and are called Command-Line Interfaces (see wikipedia). They operate off the same principals, just using different keywords to perform similar commands. It should be noted however, that the commands although similarly named, may not perform the exact same function. They are just abstractions of lower level functions of the operating system. Just like people can explain similar ideas using different words and phrases, the same applies in this situation. For reference here's a list of Bash commands: http://ss64.com/bash/ and the same website has windows commands.
The difference is the operating system. The command prompt (cmd) and a terminal emulator (linux bash shell or similar) are text interfaces to the operating system. They allow you to manipulate the file system and run programs without the graphical interface.
You should read about Linux shells. The Bash shell for instance, is among the most used Linux shells... ever!
http://doc.dev.md/lsst/ch01sec07.html
http://www.tuxfiles.org/linuxhelp/shell.html
And if you're looking for a list of commands: http://www.physics.ubc.ca/mbelab/computer/linux-intro/html/
It is not that commands are in common (well yes, maybe some), it is that they have the same name and do almost the same things, as for cd as you said.
The shells are an abstraction of the underlying operative system, Linux and Windows have a different kernel, hence the difference.
You might want to start here with your reading.
Looking for a better Windows XP command-line interface. The Visual Studio Command Prompt isn't near as nice as the Linux/OSX terminals.
Thoughts?
edit:
Answers: Console on Sourceforge, and the Windows Powershell. Thanks, I'll go dig them up and evaluate them.
The Cygwin package is too much overhead for what I want.
edit2:
Looks like the Windows Powershell for now. Its copy&paste functionality isn't great, but MS supports it.
Take a look at Console2 http://sourceforge.net/projects/console/
It's features:
"multiple tabs, text editor-like text selection, different background types, alpha and color-key transparency, configurable font, different window styles"
As has your question been tagged, have you tried Windows PowerShell? It's paradigm is based on unix's pipes but instead of outputting text the processes output .Net objects.
cygwin? www.cygwin.com. Or mingwin?
Cygwin
This is an answer extending line.
I'm not clear on what you mean by Linux/OSX command prompts being "nice". If you just mean that they provide more utilities, I usually install Windows Services for Unix to add common programs like grep and vi.
I see you put "powershell" as one of your tags. Maybe you could help direct our answers by explaining what you don't like about PowerShell as a replacement for cmd.exe?
I use Take Command from JP Software
Cygwin is a good alternative. You can run Bash or other shells on Windows. You get most of your classic Linux/UNIX commands, shell scripting, etc. You even get the GNU compilers and can avoid Visual Studio if you wish. From Cygwin, you can access your regular Windows programs, drives, etc so there's rarely a reason to go back to cmd.exe.
If you are just looking to automate tasks via shell scripts (not interactive shell), then you should look at Windows Scripting Host. WSH is a feature-rich scripting environment for Windows that comes pre-installed on all modern versions of Windows.
I've been combining putty, cygwin, screen, and zsh(not bash) lately. I like a lot of the features of zsh, like autocd which and auto-pushd, which put the directories you change into onto the directory stack without having to type pushd. I also like that fact that multiple shells share history, and don't overwrite each other. Screen lets me run multiple zsh shells in one putty window. You can get zsh and screen from the cygwin site. I run: putty -cygterm screen
You'll also need the patched version of putty that has the -cygterm support.
GitBash by git is also a good option. It can be configured to be used in unix like environment.
It can be downloaded from here http://msysgit.github.io/