181–190 of 216 posts
Earlier quoted context omitted.
http://www.vim.org/scripts/script.php?script_id=1723 vimpager. Set vim as your pager. I love reading man pages in syntax-colored vim glory.
I prefer keeping file viewing and file editing as separate actions. 'most' will colorize bash output as well (it's strictly a pager, in the pg / more / less / most continuum).
Actually the new top comment blew me away. I'm in the 20 year veteran category and was also oblivious. Quoted: disown - bash built in. You know how you always start that mega long rsync in an ssh session from your laptop and then realize you have to go offline halfway through? You forgot to start it in screen or nohup, didn't you? You can pause it (ctrl+z), background it (bg), and then disown it so it is protected fr…
Earlier quoted context omitted.
I wish there was an easy way to get info about builtin commands. So things like man bash-disown would work (similar to git).
The 'help' command is exactly what you're looking for -- e.g., 'help disown' will describe the 'disown' command. Definitely beats searching the entire bash man page for the command you want (which is what I did for far too long, until I found out about 'help').
Earlier quoted context omitted.
There's also 'tmux': http://tmux.sourceforge.net/
Which according to reports has the benefit of being maintainable. GNU screen, which I love and use to obscene extents daily, has an exceptionally hairy codebase. That said, I've got to get my tmux on and learn how to do screen equivalents with it.... http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-...
Since it is installed for the most part everywhere I have no desire to switch to tmux.
Earlier quoted context omitted.
Which according to reports has the benefit of being maintainable. GNU screen, which I love and use to obscene extents daily, has an exceptionally hairy codebase. That said, I've got to get my tmux on and learn how to do screen equivalents with it.... http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-...
I keep seeing people comment on the codebase of screen being bad vs tmux, but I'm not sure why that is an issue? Are there any features of screen missing that haven't been added to the codebase? The vertical split patch has been added a long while back, and even though I'm sure tmux has a smaller memory footprint, I've never had an occasion where screen has ever been an app I'm worried might impact my server memory u…
If there are problems found with screen (and it's a widely used admin tool that may be left running on remote servers, hence a high-value attack vector), it's going to be harder to find and fix the problem.
If there are features to be added, they'll be harder to add to screen than tmux. Which means that with time, tmux stands a higher chance of becoming more featureful.
Both argue in favor of tmux in the long run, though there's no immediate need to ditch screen. As you note, screen's very widely available, which is a feature. Then again, so was telnet 10 years ago.
Earlier quoted context omitted.
Which according to reports has the benefit of being maintainable. GNU screen, which I love and use to obscene extents daily, has an exceptionally hairy codebase. That said, I've got to get my tmux on and learn how to do screen equivalents with it.... http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-...
I keep seeing people comment on the codebase of screen being bad vs tmux, but I'm not sure why that is an issue? Are there any features of screen missing that haven't been added to the codebase? The vertical split patch has been added a long while back, and even though I'm sure tmux has a smaller memory footprint, I've never had an occasion where screen has ever been an app I'm worried might impact my server memory u…
Screen lets each part of a split screen select a different existing window. Tmux makes both parts of a split part of a single window, so you can either have two things going in one split, or have something else going on in another window, but if you suddenly decide you want two existing windows side by side, you can't do it.
Earlier quoted context omitted.
How would you make the bash manpage short and to the point, considering the complexity that it implements?
By reducing the needless complexity that it implements. The purpose of a Unix shell is to interpret a simple language wrapping syscalls so the user can easily give instructions to the kernel. There are several such shells whose source code is smaller than the bash manpage. 13 pages of the 80 page manual are devoted to readline and programmable completion. Readline and programmable completion could be removed from the…
Earlier quoted context omitted.
Many comments seem to be shell- and bash-related. Perhaps the thread exposes how difficult to read the bash manpage is. On my system, the bash 4.1 manpage is 41026 words long, or about 80 pages. Manpages are most useful to me when they are short and to-the-point so I can find what I am looking for before I lose interest in skimming through an 80 page book.
I'm baffled all the time by the lack of clear examples on many manpages.
Most Linux distros have a bug reporting feature which could be used to suggest such examples, and it would be a Good Thing if more were suggested.