I'm making a command interface for a node server, but I have reached a point that I want it to look better.
I want to have the console so you enter a command at the bottom of the terminal screen, you hit enter, and it adds the reply to the actual command line.
If you have ever run a minecraft bukkit server from the command line, you should know what I'm talking about.
Here's a picture of what I'm talking about if you still don't understand. Imagine this was in terminal, and ignore the scroll bars: http://cl.ly/1K0h1V0r0H3f3U3t3L22
Is there anyway to set the console to look like this without having to make your own program for it or having the screen reprint all the other info to fake that look?
I have not done this, but I believe something similar is possible with very little effort by using Node.js REPL. You can override the eval parameter to provide your own command processing.
It would not have the exact look you are wanting, but it will be an interactive prompt that you can utilize (more similar to a Windows command shell or a Linux shell).
If you want the exact look from your screenshot, I don't believe that there is any Node.js module that will help you. There are some that allow you to use colors in the console, and some basic highlighting (e.g. bold), but nothing that gives you complete control over the console screen.
Related
I am currently running a python3 script in Ubuntu server 18.04. When i type new commands into the command line it just prints the commands. My terminal window looks like this:
mitch#server:`$ cd /home/mitch/folder
mitch#server:`/folder$ python3 main.py
file running ...
text i input just shows like this
I need to keep the script running and run other commands, how do i navigate back to:
mitch#server:`
I'm new to servers/Ubuntu/commands so this may seem trivial! Thank you
So you can't "navigate" back to that, since you're technically already there, you're just running a script in your shell which is occupying your shell - think of it like you opened a program in full screen.
But you have a few options:
The most basic is to run the script in the 'background' this is a simple as adding a & to the end of your command (note that it will still send any message from the script into your terminal - if your script is programmed to send messages that is).
Another option is to use a terminal multiplex like which lets you have multiple terminals open, as well as split screen terminals and many other features. One of the more popular multiplexers is called tmux, just keep in mind that it does have a bit of a learning curve to it, but is extremely useful once you learn it.
I am using putty (0.64.0.0 2015) to access the terminal on an AIX server. Normally typing long commands works just fine but somehow something weird happened and when I type long commands Linux cursor goes back on the same line even behind the 'bash' word.
In order to explain the problem I have a picture. Just to explain in the picture I start with capital 'ABC' then '1-10' and then small 'abc' and then repeat this sequence to simulate a long command.
Can anybody please explain why this is happening (it has also happened before) and how to solve it without restarting putty? Does it have to do with a buffer of some kind since the command runs just fine it is only that it looks like this in the picture.
It looks like your shell is no longer aware of its terminal's dimensions. Perhaps you've resized the PuTTY window after logging in?
Sometimes resize will fix such issues.
Excuse me for the imprecisions in the question but I don't know how it is called what I'm trying.
In the CodeShip documentation is stated that I can pass to the SSH CodeShip debug build some commands using their command line application.
So, I should do something like cs setup-commands and I'm prompted with this:
rof#railsonfire_unique_string_sfivbe8bwucb9:~$ cs setup-commands
Your setup commands:
phpenv local 5.6
phpenv local 5.6
In Your setup commands: I put my commands but then, how can I "execute" them?
The second phpenv local 5.6 line is wrote by the command-line application. I think is something to signal the command were taken, but the behavior is ever the same: I remain "blocked" in the command setup-commands. After setting setup-commands I have to set also test-commands but all the things I write are taken by Your setup commands:.
How can I "submit and exit" the command setup-commands to then launch test-commands and set those other commands?
I think this is something related to Bash, but I don't know what it is...
And I don't know which is the correct terminology.
Can someone help me with this? So I will can also update my question to be more precise. Thank you.
Not sure about your case, but usually the input is considered finished, when th input file (in your case stdin) is closed.
Try to press Ctrl+D, it should end your input (and so signal the program hat you stopped typing for this session)
I can scroll trough bash output using shift+pgup/pgdown.
But lets say, some command outputted lot of text, I have to pageup few times to go to beginning of output of this command.
Can I just simply do this by some shortcut? Something that simply allows me to scroll between previous commands (not history!), seeing their output.
You could try piping the output into less:
someCommand | less
less will allow you to search and scroll through the output text pretty easily.
once in less you can just type % to jump back to the top of the page. Essentially that means jump to 0% of the page. There are also a bunch of extra commands on the page I linked to above.
Another option is to use screen and use backward search (beware: read the Overview first, especially the part about the C-a prefix) to e.g. search for some specific characters in your prompt (like your username).
The scroll back history in Unix shells is a shell specific functionality, meaning that it is up to the specific shell (xterm, rxvt, text console, etc) to handle it. The functionality you request would require the shell to identify the individual program runs, to know where to scroll to. Scanning text is not technically hard per se, but as prompts and command display can differ due to user settings it can be hard to make it work generally good. Some communication between the shell and the terminal could make it better.
There sure are some nice fancy terminal programs doing things like this, to for example show syntax help when writing commands, but for your case I agree with previous answer, that piping commands to less is a good way to isolate the output. It might be a bit cumbersome first, as it requires you to think about it first, and not just go back in history, but if you learn the shell better and learn to use the command history it will probably work fine. I recommend you to, if you haven't already. What I mean is ctrl-r etc. More described for example here:
http://www.catonmat.net/blog/the-definitive-guide-to-bash-command-line-history/
I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.