Which shell do you use?

I just tried the mksh shell, I could use it under one circumstance ... it must support !$, let me explain:
ZSH/CSH/BASH:
Code: 
# ls /boot
# cd !$
cd /boot

MKSH:
Code: 
# ls /boot
# cd !$
mksh: cd: /!$ - No such file or directory

Generally !$ meanse LAST argument of previous command, pretty goddamn usefull in interactive mode.
 
vermaden, try [alt]+[dot] (this will expand the last argument of the previous command, pasting it at the cursor position). Repeat for browsing previous arguments.
 
Thanks for suggestion, but that does not seem to work.

The left [ALT]+[.] does not do anything, the right [ALT]+[.] puts something like 'middle dot' and returns an error after [ENTER]:

Code: 
# ls /boot
# ls · 
ls: ·: No such file or directory
 
Weird ;) Works fine here, with the 'left alt' and the 'right alt (alt gr)'. I use straightforward us-ascii though. Both insert /boot when the previous command was ls /boot. I've seen other methods (or at least mksh feature requests) that seemed to work with something like 'm-.' and/or 'M-.', but I have no idea how these would work.

There's also this in the manual (emacs mode):
[cmd=]man mksh | less +/" Emacs editing mode"[/cmd]

Code: 
     prev-hist-word: [n] ^[., ^[_
             The last (nth) word of the previous (on repeated execution, sec-
             ond-last, third-last, etc.)  command is inserted at the cursor.
             Use of this editing command trashes the mark.

I guess I miss the necessary genetic markers to fathom this. But it's clear that the logic to retrieve/reproduce the last argument is definitely in there somewhere.
 
@vermaden:

It's basically /usr/local/share/examples/mksh/dot.mkshrc with a very minor alteration to the PS1 line to get a nicer prompt. And my $TERM is 'xterm', by the way.
 
I have also tried that, it does not work with [ALT] but with [ESC] for me, seems that I do not have somewhere 'meta sends esc' option enabled.
 
Heh ... [ESC] + [.] also works here ;)

The only difference is that I can cycle with [Alt] + [.] [.] [.] [.] etc., but have to use [ESC] + [.] [ESC] + [.] [ESC] + [.]
 
Alt-x as Meta is not supported, DutchDaemon: Meta-. yields ® really. Use Esc+x instead (note foo-bar = hold them together, foo+bar = press them in sequence notation). ^[x means Esc+x just as ^X means Ctrl-X – Ctrl-[ is ESC in ascii(7).

Czesc vermaden, mksh feature requests (and support, I suppose) go via IRC (channel #!/bin/mksh or #ksh on Freenode) or, if must be, mailing lists. (Or Launchpad… if absolutely must be.) IRC is the fastest/best/easiest.

^[. does have a feature request open (in the Debian BTS). I don’t think the specialness of the exclamation mark will find its way into mksh though (it also would break just too many scripts), and the presence of the “wbx hack” (PS1 response beginning with "!" is converted into "r ") is a mistake.

Hi ckester, nice to see ☺ Note that some things are terminal dependent, for example, in wsvt25 (wscons, the BSD equivalent to FreeBSD’s cons25) there’s no difference between Ctrl-CurLeft and just CurLeft, so the shell cannot know that. On others, the keys are simply not known, but you can usually use the bind builtin to configure that yourself.

.oO(In MirBSD, there’s no toor and never has been, and root is usually not usable, doesn’t even have a password or home directory, real men use sudo(8), see http://xkcd.com/838/ ☻)

Blueprint, on some NetBSD mailing list, there’s a discussion about pdksh/mksh/ksh93, and it seems that ksh93 cheats a little to be faster (plus it has a bytecode compiler, but IMO a lot of bloat and inferiour command line editing – YMMV though). I’m okay with Dave Korn, and he’s okay with mksh as long as I try clearly to get people to not confuse it with AT&T ksh. And mksh is by no means new, just its “product placement”. It’s actively developed though (like ksh93).

Off again,
//mirabilos (Mr. mksh)
 
Mel_Flynn said:
Code: 
make -C /usr/ports/shells/bash -D WITH_STATIC_BASH -DWITHOUT_NLS PREFIX=/ install

Library problem and "no mounted /usr" problem solved. The rest is paranoia. It's easy to change the shell back to csh for problem reporting if you suspect the shell to play a roll with your bug.
su(1) has quite a few advantages over sudo as shell/command wrapper, especially in machine stress situations and because sudo tries to be too smart about your environment variables.
Of course, the conservative "feed the newbies babyfood" answer is to not change root shell.
Click to expand...

also to add further, changing root's shell still allows login with toor on default shell, should a bash problem occur.
 
UNIXgod said:
+1 but I never change my shell under root. even if it's avalable. Even the zsh guys don't suggest it for root.

I can't begin to explain the problems that could occure if the root shell is changed.
Click to expand...

please explain since I have ran root using bash for a numbr of years without noticing problems.

the only problem I know off really is if the bash binary breaks preventing login.
 
chrcol said:
please explain since I have ran root using bash for a numbr of years without noticing problems.

the only problem I know off really is if the bash binary breaks preventing login.
Click to expand...

Well since a lot of us work on remote systems off-site, sometimes a long way away, that is a pretty large problem. There are still a ways that binary can break(not all /usr are located on the same disk / is) so given that bash as an interactive shell doesn't hold a lot of advantages over something like tcsh then I guess the standard advice is still good advice. The static binary approach would be less than ideal for memory constrained system running a bunch of bash scripts and if you aren't running a bunch of bash scripts it's really debatable if bash gives you an advantage.

It's more of a "Should you change the root shell" vs "Can I change the root shell" question and that's best answered by the person/group administering the system. If bash gives useful functionality not present in tcsh and you're ok with the risk and hassle then switch.
 
I also remotely administer servers.

in over 5 years I think I have had bash break twice, the last time it happened I was aware of toor and it was a non issue as I simply logged into toor, and recompiled bash to fix it.

I have a few issues with the default shell, mainly.

rehash - urrgh
poor command history system
less compatible with most scripts out there.
my prompt variable doesnt work on it.

its down to choice which I am fine with, but am wondering if this changing root shell thing is simply overstated given that there is a recovery account.
 
chrcol said:
I also remotely administer servers.

in over 5 years I think I have had bash break twice, the last time it happened I was aware of toor and it was a non issue as I simply logged into toor, and recompiled bash to fix it.
Click to expand...
You must mean you were aware of toor prior to your issue and enabled it. Making toor available to a remote login isn't something that's good practice if that's what you did.

rehash - urrgh
Click to expand...
Difficult to respond to. rehash and the frequency required has never caused me a second thought.
poor command history system
Click to expand...
I guess that's a per-user preference because that's primarily the reason I hate bash. It's command history filter is near useless IMO. Most of the time it's just easier to retype the whole thing under bash. tcsh and the FreeBSD defaults allow me to quickly find complex commands I've already got in history.
less compatible with most scripts out there.
Click to expand...
Actually most scripts are shebang'd to run with the shell they were written for which is hopefully /bin/sh. Many also test for the proper shell before executing main code. Also please note this is about the interactive, not scripting shell. I'm not saying you should use
Code: 
#!/bin/tcsh
in your scripts.
my prompt variable doesnt work on it.
Click to expand...
Use the appropriate tcsh variables and you won't have a problem.

its down to choice which I am fine with, but am wondering if this changing root shell thing is simply overstated given that there is a recovery account.
Click to expand...
I don't think so. It's typically a new user issue(coming from linux) and toor account is disabled by default. Expecting the new user to remember and deal with all the complications of changing the root shell is just asking for trouble.
 
chrcol said:
please explain since I have ran root using bash for a numbr of years without noticing problems.

the only problem I know off really is if the bash binary breaks preventing login.
Click to expand...

I though this was answered or is this just bait?
 
why are people mentioning enabling toor?

I have done nothing to specifically enable toor and am able to use it on newly deployed servers.

also I am not baiting anyone.
 
chrcol said:
why are people mentioning enabling toor?

I have done nothing to specifically enable toor and am able to use it on newly deployed servers.
Click to expand...

Because if you haven't enabled the toor account, the only way you can utilize it is an # su from a super-user account. You cannot login with a default toor account meaning there's no way to fix your bash error you claimed to earlier via toor unless you have explicitly setup the account.

Run # vipwlook at the toor line. Notice the '*' in the second field? That mean that account cannot login.

Either way, you're wrong on something.

FWIW, there is nothing inherently special about the toor account, it's just another UID 0 that comes disabled by default.
 
You must log in or register to reply here.
Back
Top