Hot answers tagged nano
You pressed Ctrl+S instead of Ctrl+O to save the file. Ctrl+S is an old flow-control key combination to pause the transmission, and stop scrolling, of data to a terminal (internally, the code sent is called XOFF). Ctrl+Q (XON) is the complement to start transmission and resume scrolling. Nano ignores these code since it doesn't use scrolling. The ...
You typed the XOFF character Ctrl-S. In a traditional terminal environment, XOFF would cause the terminal to pause it's output until you typed the XON character. Nano ignores this because Nano is a full-screen editor, and pausing it's output is pretty much a nonsensical concept. As to why the wording is what it is, you'd have to ask the original devs.
No, you can't give a running program permissions that it doesn't have when it starts, that would be the security hole known as 'privilege escalation'. Two things you can do: Save to a temporary file in /tmp or wherever, close the editor, then dump the contents of temp file into the file you were editing. sudo cp $TMPFILE $FILE. Note that it is not ...
It should be pointed out that Mac OS X uses \n a.k.a linefeed (0x0A) now, just like all other *nix systems. Only Mac OS versions 9 and older used \r (CR). Reference: Wikipedia on newlines.
In Vim you can also just do the global replace on the start of all lines: :%s/^/;/
The pipe symbol is sending the ouput of nano to the input of the uniq command. However, nano is still running and receiving your keyboard input. It's just that you can't see its ouput as uniq won't ouput it's results until it sees an End-Of-File (this isn't important to the question). When you press ctrl-c it is 'caught' by nano, but it does not cause it ...
The only thing coming close to what you want is option to display your current cursor position. You activate it by using --const (manpage: Constantly show the cursor position) option or by pressing AltC on an open text file.
In Vim: gg0<ctrl-v>GI;<Esc>
Just searched for nano line wrapping and this came high in results, so I'll post my findings for GNU nano 2.2.6 on the Raspberry Pi, Raspbian GNU/Linux 7: Esc+L gave me the same message; but for the line wrapping to take effect I had to modify the line. As soon as I typed another character on the long line, wrapping kicked in.
To do this on a CoreOS box, following the hints from the guide here: Boot up the CoreOS box and connect as the core user Run the /bin/toolbox command to enter the stock Fedora container. Install any software you need. In this case, it would be as simple as doing a dnf -y install nano (dnf has replaced yum) Use nano to edit files. "But wait -- I'm in a ...
Once you have selected the block, you can use Alt + } to indent it.
You have to use Ctrl+x to exit nano and install new crontab. Ctrl+z will just stop/send to background nano without installing new crontab. See attached screenshot:
To see the word wrapping you are expecting, use Esc+$ However, be careful if you're editing a configuration file or code or something that is sensitive to newlines and/or indents. I suggest making sure Soft line wrapping is off in those cases.
With those syntax-highlighting rules files, nano assumes that filenames ending in .1 - .9 are man pages. It's been quite a while since I edited a man page, but I'm pretty sure that in groff -man, .I is for italic and .Bis for bold.
For a simple task like this you could use sed or perl. For a small footprint, use sed for this simple task: sed -i.old -e 's/^/;/' file This preserves a copy of the original file as "*.old" and adds a ";" at the beginning of every line. In the event that your sed isn't a GNU version (as is the case on many Unix variants), it is likely that you won't ...
jw013 points out in another answer that Mac has now switched to the *nix standard \n. Previously, Mac OS was \r (carriage return, 13/0x0D); Windows is \r\n, and *nix are \n (linefeed, 10/0x0A). I'm not certain for the more obscure systems, but I'd guess nearly everything else is also \n. The difference comes from the days of the teletype when \n would ...
If you press Ctrl+U immediately after Ctrl+J, the justification is undone. Nano in fact tells you (the ^U shortcut description at the bottom changes from UnCut Text to UnJustify). No, I won't blame you for not noticing that. You can't unjustify if you've typed anything after Ctrl+J. Yes, that's pretty underwhelming (far from a general undo).
Nano is by design a very simple editor with few features. If you start wishing for anything beyond basic edition, nano isn't the right tool. Emacs is a very powerful editor; to switch line numbers on, type M-x linum-mode. If Emacs scares you and you want a text mode editor, consider Joe, where line numbers are switched on with the -linums option.
From the tmux FAQ: ****************************************************************************** * PLEASE NOTE: most display problems are due to incorrect TERM! Before * * reporting problems make SURE that TERM settings are correct inside and * * outside tmux. * * ...
As other answers have already explained, Ctrl+C doesn't kill Nano because the input of nano is still coming from the terminal, and the terminal is still nano's controlling terminal, so Nano is putting the terminal in raw mode where control characters such as Ctrl+C are transmitted to the program and not intercepted by the terminal to generate signals. When ...
I did some research and find it is not too hard. To open the current selected file in ranger in a new pane (to the right) in an ad-hoc manner, you can first go to ranger's command line (by pressing :) and then type shell tmux splitw -h 'vim %f' following by the <Enter> key. To achieve this with some key binding, you can set it in a configuration file ...
You can use the stat command to check the file's modification time before and after nano. Something like: oldtime=`stat -c %Y "$filename"` nano "$filename" if [[ `stat -c %Y "$filename"` -gt $oldtime ]] ; then echo $filename has been modified fi Of course, this won't detect whether nano modified the file, or some other program did, but that could be ...
Strike Ctrl+X. Nano captures all keyboard input and inside Nano Ctrl+C has an entirely different meaning than in the shell. If you run a nano in a separate window, you can easily see what keys you have to enter to exit. Ctrl+X
The shell doesn't receive you Ctrl+C, nano does. Programs are able to define custom behavior for interrupt signals and nano is one such program. To see what the custom behavior is open nano without the redirection and send it a Ctrl+C.
The feature wasn't added until version 2.2 http://www.nano-editor.org/dist/v2.2/TODO For version 2.2: Allow nano to work like a pager (read from stdin) [DONE] and CentOS6 uses nano-2.0.9-7 (http://mirror.centos.org/centos/6/os/x86_64/Packages/) If you decided you want the latest version, you can download from the upstream site ...
I just tried nano, and what I found most surprising is it doesn't even warn you that the file is read-only when you start trying to edit the file. (UPDATE: Apparently nano 2.2 does warn; 2.0 doesn't.) Here's a (basic) script that does that. It checks if you can edit the file, and if you can't, it runs "nano" as root instead. /usr/local/bin/edit (or ...
I found the problem by comparing my saved session in PuTTY for the "problem" server to one for a "working" server. Under the terminal emulation options, I had "DEC Origin Mode initially on" checked. Unchecking this option solved the problem.
I am a little confused by the statement running "PuTTY over ssh". I assume you mean using PuTTY to connect to a Linux server via the SSH protocol (sorry, it's so wordy, just want to clarify). When using PuTTY, TERM should always be xterm as PuTTY (and many other graphical terminals) emulate the old xterm Terminal Emulator. The TERM value Linux implies you ...
An editor may or may not be multi-threaded, but, even if it is, it is unlikely to use threads for this purpose for one simple reason: doing so would not provide any advantages for normative use, and it would no doubt create developer headaches and possibly compromise features that are considered important (for normative use). Given an infinite amount of ...
Syntax highlighting tends to be language specific. However, if you want to do it for all files, you can simply create a very very simple language definition. I took the Perl syntax style (which treats lines starting with # as comments) from /usr/share/nano/perl.nanorc and adapted it to: syntax "All" "." color green "^\s*#.*" As far as I can tell, the nano ...
Only top voted, non community-wiki answers of a minimum length are eligible