Solaris Shells

Standard shell on Solaris is POSIX shell which is a weaker shell then either ksh93 or bash. Default shell for Solaris is the "Bourne shell" or /usr/bin/sh  It's a pretty weak outdated shell; nothing to speak about and the idea that it somehow increases the security of root due to the fact that it is static linked is one of Solaris urban myths (see Solaris Root Shell Mini-FAQ for details). It's actually pretty safe to replace it as a root shell. It might slightly increase the chances of recovery in case /usr  partition is damaged, but this is a pretty serious case and usually means serious troubles with other partitions on the disk anyway (unless this is the case when link /bin -> usr/bin is destroyed, but such cases are simple to fight by refereeing shell as /use/bin/ksh in passwd). If this is a serious trouble then booting from a CD and mounting the damaged volume is always a good idea and in this case it does not matter what shell root is using; you can change it anyway.

Solaris Posix shell is ksh88 plus some ksh93 enhancements and is not as powerful as ksh93. It's pretty stupid not to use ksh93 those days and here Sun developers should accpt the blame of being exremly stupid. 

Bash is also a good interactive shell, the first Bourne line shell that can compete on user-frendliness with tcsh. But it has GNU christnas tree problems (libraries this, libararies that). also you cannot use it as a role shell.  Some interesting features of bash 3.0 include:

• ! history retrieval 
• arrows keys history browsing
• Indexed arrays of unlimited size
• Integer arithmetic in any base from two to sixty-four
• shell debugger

The command line editing capabilities of bash are very good. Bash allows to perform "bang commands" repeatedly, saving you a lot of typing (via the "!<digit> syntax).

BASH  3.0 also introduced some important ksh93-style enhancements, for example it does has process substitution in pipes (  > (command) and < (command) ). Each command argument of the form <(list), >(list) or =(list) is subject to process substitution. In the case of the < and > forms, the shell will run process list asynchronously, connected to a named pipe (FIFO). The name of this pipe will become the argument to the command. If the form with > is selected then writing to this file will provide input for list.  This also allows you to use the output of several commands simultaneously as input for another program. For instance you can compare the contents of two directories by typing:

diff <( ls dir1 ) <( ls dir2 )

That can be used for concatenating input in pipes.

cat <(echo hello) <(echo world) | echo

If < is used, then the file passed as an argument will be a named pipe connected to the output of the list process.

Another, more complex,  example,

paste <(cut -f1 file1) < (cut -f3 file2) | tee >(process1) >(process2) >/dev/null

cuts fields 1 and 3 from the files file1 and file2 respectively, pastes the results together, and sends it to the processes process1 and process2. Note that the file, which is passed as an argument to the command, is a system pipe so programs that expect to lseek(2) on the file will not work. Also note that the previous example can be more compactly and efficiently written as:

paste <(cut -f1 file1) <(cut -f3 file2) >>(process1) >>(process2)

The shell uses pipes instead of FIFOs to implement the latter two process substitutions in the above example.

If = is used, then the file passed as an argument will be the name of a temporary file containing the output of the list process. This may be used instead of the < form for a program that expects to lseek(2) on the input file.

Other interesting features include (from the FAQ):

• new `time' reserved word to time pipelines, shell built-ins, and shell functions
• one-dimensional arrays with a new compound assignment statement,
• appropriate expansion constructs and modifications to some of the built-ins (read, declare, etc.)
• new quoting syntaxes for ANSI-C string expansion and locale-specific string translation
• new expansions to do substring extraction, pattern replacement, and indirect variable expansion
• new built-ins: `disown' and `shopt'
• new variables: HISTIGNORE, SHELLOPTS, PIPESTATUS, DIRSTACK, GLOBIGNORE, MACHTYPE, BASH_VERSINFO
• new prompt expansions: \a, \e, \n, \H, \T, \@, \v, \V
• history and aliases can be used in shell scripts, not only in interective sessions.  
• new readline variables: enable-keypad, mark-directories, input-meta, visible-stats, disable-completion, comment-begin
• new readline commands to manipulate the mark and operate on the region
• new DEBUG trap
• expanded (and now documented) restricted shell mode

NEWS CONTENTS

• 200305 : Conditional Init Constructs within readline ( )
• 200305 : Some features of wcd: ( )

Old News ;-)

Solaris Root Shell Mini-FAQ

Some sysadmins still recommend against changing the root shell on Solaris systems. Ask why and you may be told that root needs a statically linked shell which is not dependent on the dynamic libraries under /usr/lib. This was true in the past but is not necessarily the case today. Solaris, when properly configured, is like any other version of Unix and can support whatever shell you define, for root or any other account. The reason root's default shell (/sbin/sh) is statically linked is historical. Back when 127MB was considered a large disk /usr (and the libraries under /usr/lib) had to be mounted from a second disk or NFS server. When a system boots into single-user mode it does not mount partitions other than /, breaking any dynamically linked program. The solution to this is simple: don't partition /usr and avoid the resulting point of failure. Since the advent of larger hard drives there has not been a good reason to partition /usr. Other Unix distributions have been reliable without system partitions or statically linked binaries for several years now. The shell specified in /etc/passwd is root's interactive shell and should be suited for command-line usage.

As long as you have not partitioned /usr and your root's shell is also on the root partition you can safely use bash, tcsh, ksh or any other shell for the root account. This Mini-FAQ addresses the misconceptions which are often given as reasons for not changing the Solaris root shell.

Misconception 1: The password file will get misedited and the root account will be locked-out. While it's always possible to mis-edit /etc/passwd using a text editor this does not mean that the root shell should not be changed. It does mean that the password file should be edited with "vipw" instead of "vi /etc/passwd".

Misconception 2: SunSolve FAQs and SRDBs strongly suggest that you not change root's shell. Perhaps this was true several years ago but a cursory search for [root shell] turned up a number of articles explaining how to change the root shell safely (FAQ ID 2707, SRDB 6282, and SRDB 6307).

Misconception 3: Cron scripts will not work if the root shell is changed. Cron scripts are run under the Bourne shell regardless of the root shell. This has been the case since at least SunOS 3, if not SunOS 1.

Misconception 4: A dynamically linked root shell will be unusable if /usr/lib becomes corrupted or moved. This is true, however, the vast majority of Unix sysadmins will never see this occur in their careers. More importantly, /usr is no more likely to become corrupt than /sbin. Finally, if you munge /usr or /usr/lib it's likely you will need more than /sbin/sh in single-user mode to fix it since ftp, rcp, ufsrestore, and other key utilities are all dynamically linked and/or under /usr. Even the ls command is dynamically linked. If you do manage to mangle /usr/lib, say from an accidental rm, it won't matter what shell root defaults to. The only way to fix it will be to boot from CD.

Misconception 5: The startup scripts under /etc/rc* will not work if the root shell is changed. This was partly true several years ago. From 2.3 onward (1994?) all system rc scripts are executed under sh regardless of the root shell (see /etc/rcS).

Misconception 6: Sysadmins are spending too much time as root if they want to change the shell. Professional systems administrators normally spend a large portion of their time as root. It is a requirement of the job. While it certainly is true that tasks which can be performed as a non-root user should be this does not mean that Unix sysadmins have no legitimate reasons for working as root nor that these admins cannot be more productive with a modern shell.

Misconception 7: You'll need a CDROM drive on any machine where the root shell is changed, in case you need to boot to another password file. This is incorrect. As long as the root shell is correctly defined, on the root partition, and /usr/lib is on the root partition there will be no problem booting single-user and logging-in as root using a dynamically linked shell. If your system has a partition for /usr or /usr/lib it would be prudent to move it to the root partition. Depending on a server's applications /home, /var/spool, /var/sadm, /var/tmp, /opt, and /usr/local can be symlinked or partitioned and mounted from another drive but /usr should not normally be separated from the root partition. Also, quoting Solaris FAQ maintainer Casper Dik: the "most important reason for not having a separate /usr: if anything gets mounted, /usr will be there."

Misconception 8: Unless you have a good reason to change the root shell it is better to leave it alone. This is one piece of good advice, however, if there were no good reasons changing it would not be such a common practice.

Misconception 9: It's just as easy to run another shell when you login or su. If that were the case this question probably would not come up so often.

Misconception 10: There are many reasons to not change the root shell all you need to know is to never do it again. Claims that anything is "all you need to know" are generally not correct.

Resolution: Solaris 9 After several years of requests Sun addressed this in SunOS 5.9 (marketed as Solaris 9) by allowing for a fail-over login shell. Beginning with (5.)10 Solaris will no longer have static binaries. This will eliminate the static /sbin/sh as all shells, root and otherwise, will be dynamic. The resulting OS will be considerably simpler to install, patch and maintain.

[Jan 2, 2005] bash-support.vim - Write BASH-scripts by inserting comments, statements, tests, variables, builtins vim online

Write BASH-scripts by inserting comments, statements, tests, variables and builtins.
Speed up writing new scripts considerably.
Write code und comments with a professional appearance from the beginning.

Here are some screen shots : http://lug.fh-swf.de/vim/vim-bash/screenshots-en.html

This plugin comes with a help file (bashsupport.txt).
Read it with

:h bashsupport

GeSHi - Generic Syntax Highlighter Home can be used for shell scripts and bash initrc

Bash Config Files

How Bash executes startup files.

For Login shells (subject to the -noprofile option):

On logging in:
If `/etc/profile' exists, then source it.

If `~/.bash_profile' exists, then source it,
else if `~/.bash_login' exists, then source it,
else if `~/.profile' exists, then source it.

On logging out:
If `~/.bash_logout' exists, source it.

For non-login interactive shells (subject to the -norc and -rcfile options):
On starting up:
If `~/.bashrc' exists, then source it.

For non-interactive shells:
On starting up:
If the environment variable `ENV' is non-null, expand the variable and source the file named by the value. If Bash is not started in Posix mode, it looks for `BASH_ENV' before `ENV'.

So, typically, your `~/.bash_profile' contains the line
`if [ -f `~/.bashrc' ]; then source `~/.bashrc'; fi' after (or before) any login specific initializations.

If Bash is invoked as `sh', it tries to mimic the behavior of `sh' as closely as possible. For a login shell, it attempts to source only `/etc/profile' and `~/.profile', in that order. The `-noprofile' option may still be used to disable this behavior. A shell invoked as `sh' does not attempt to source any other startup files.

When Bash is started in POSIX mode, as with the `-posix' command line option, it follows the Posix 1003.2 standard for startup files. In this mode, the `ENV' variable is expanded and that file sourced; no other startup files are read.

My .bashrc can be found here.

My .bash_profile can be found here.

.inputrc (readline)--

Although the Readline library comes with a set of Emacs-like key bindings installed by default, it is possible that you would like to use a different set of keybindings. You can customize programs that use Readline by putting commands in an "init" file in your home directory. The name of this file is taken from the value of the shell variable `INPUTRC'. If that variable is unset, the default is `~/.inputrc'.

When a program which uses the Readline library starts up, the init file is read, and the key bindings are set.

In addition, the `C-x C-r' command re-reads this init file, thus incorporating any changes that you might have made to it.

Conditional Init Constructs within readline

Readline implements a facility similar in spirit to the conditional compilation features of the C preprocessor which allows key bindings and variable settings to be performed as the result of tests. There are three parser directives used.

`$if'	The `$if' construct allows bindings to be made based on the editing mode, the terminal being used, or the application using Readline. The text of the test extends to the end of the line; no characters are required to isolate it.
`mode'	The `mode=' form of the `$if' directive is used to test whether Readline is in `emacs' or `vi' mode. This may be used in conjunction with the `set keymap' command, for instance, to set bindings in the `emacs-standard' and `emacs-ctlx' keymaps only if Readline is starting out in `emacs' mode.
`term'	The `term=' form may be used to include terminal-specific key bindings, perhaps to bind the key sequences output by the terminal's function keys. The word on the right side of the `=' is tested against the full name of the terminal and the portion of the terminal name before the first `-'. This allows SUN to match both SUN and SUN-CMD, for instance.
`application'	The APPLICATION construct is used to include application-specific settings. Each program using the Readline library sets the APPLICATION NAME, and you can test for it. This could be used to bind key sequences to functions useful for a specific program.
`$endif'	This command terminates an `$if' command.
`$else'	Commands in this branch of the `$if' directive are executed if the test fails.

The following command adds a key sequence that quotes the current or previous word in Bash:
$if bash
# Quote the current or previous word
"\C-xq": "\eb\"\ef\""
$endif

My .inputrc file is here

Last update by Hermann Heimhardt on October 7, 2001

Patch against 2.05 Bash to make cd take 2 Args like ksh

From:	Eli
Subject:	Patch against 2.05 Bash to make cd take 2 Args like ksh
Date:	Fri, 22 Jun 2001 14:38:17 -0400

---

*** origBash/bash-2.05/builtins/cd.def  Wed Oct 11 11:10:20 2000
--- bash-2.05/builtins/cd.def   Fri Jun 22 14:31:08 2001
***************
*** 187,192 ****
--- 187,225 ----
        }
        lflag = interactive ? LCD_PRINTPATH : 0;
      }
+   else if (list->next)
+     {
+       /* if next then 2 args, so replace in PWD arg1 with arg2 */
+       int beginLen, oldLen, newLen, endLen;
+       char *replace;
+       path = get_string_value ("PWD");
+       if (( replace = strstr( path,list->word->word)) == (char *)0 )
+         {
+          builtin_error ("Couldn't find arg1 in PWD");
+          return (EXECUTION_FAILURE);
+       }
+       beginLen = replace - path;
+       oldLen = strlen( list->word->word);
+       newLen = strlen( list->next->word->word);
+       endLen = strlen( path + beginLen + oldLen ) + 1 ;
+ 
+       dirname = xmalloc( beginLen + newLen + endLen );
+       /* copy path up to begining of string to replace */
+       memcpy( dirname, path, beginLen );
+ 
+       /* then add new replacement string */
+       memcpy( dirname + beginLen, list->next->word->word, newLen );
+ 
+       /* finally add end of path after replacement */
+       memcpy( dirname + beginLen + newLen, path + beginLen+
oldLen,endLen);
+ 
+       printf("%s\n",dirname);
+       if (change_to_directory (dirname, no_symlinks))
+       {
+          free(dirname);
+          return (bindpwd (posixly_correct || no_symlinks));
+       }
+     }
    else if (absolute_pathname (list->word->word))
      dirname = list->word->word;
    else if (cdpath = get_string_value ("CDPATH"))

[Nov 26, 2004] kcd Home Page

kcd is a directory change utility under Linux or any other Unix clones. It helps you navigate the directory tree. You can supply the desired directory name in the command line and let kcd find it for you or let kcd show the entire directory tree and use arrow keys to go to the destination directory.

Here is a list some features available in kcd:

	Fast directory rescanning. All directory timestamp is saved so that certain directories do not need rescanning if they are not changed.
	When supply directory in command line and kcd find too many matches. kcd shows all of them and let you select using cursor keys.
	You can tell kcd to skip some directory. You can also chose whether you want the whole directory tree, inside your home directory, etc. They can be set in kcd configuration file.
	Supports bash, ash, pdksh, zsh and tcsh.
	Multiple configuration profiles.
	Priority directory matching via bookmark.
	Fuzzy directory searching (Contributed by Robert Sandilands).
	Supports UTF-8 Unicode encoding with combining characters.
	Supports localization.
	Default, vi, and emacs key binding modes.
	Partial directory tree display.
	Display directory tree without saved data.

kcd is available as stable version and development version. You can distinguish development version from stable version by looking at its version number. Beginning from version 5.0.0, any version x.y.z where y is even is a stable version. Those where y is odd is a development version. Features currently present in the development version will eventually appear in the future stable version 8.0.0.

kcd is distributed in source form under General Public License (GPL).

The program and this web page is maintained by Kriang Lerdsuwanakij

[Nov 15, 2004] Erwin Waterlander, WCD Wherever Change Directory Another Norton Change Directory (NCD) clone with more features.

Wcd is a program to change directory fast. It saves time typing at the keyboard. One needs to type only a part of a directory name and wcd will jump to it. By default wcd searches for a directory with a name that begins with what has been typed, but the use of wildcards is also fully supported.
For instance:

wcd Desk

will change to directory /home/waterlan/Desktop

But also

wcd *top

will do that.

Wcd is free to use and you can get the source code too.

Some features of wcd:

Full screen interactive directory browser with speed search.

Present the user a list in case of multiple matches.

Wildcards *, ? and [SET] supported.

Directory stack, push pop.

Subdir definition possible. E.g. wcd subdira/subdirb

Long directory names support in Win95/98/NT DOS-box

Windows LAN UNC paths supported.

Change drive and directory at once.

Alias directories.

Ban directories.

'cd' behaviour

Free portable source-code, no special libraries required

Multi platform:
DOS 16 bit, DOS 32 bit, DOS bash, Windows 3.1/95/NT DOS-box, Cygwin bash, Unix ksh, csh, bash and zsh.

Wcd has been tested on: FreeDOS, MS-DOS 6.2, Win95, Win98, Windows NT 4.0, Linux, FreeBSD, HP-UX, SunOS, Solaris, SGI IRIX. Wcd works on any PC and can be ported to any Unix system.

WCD is free software, distributed under GNU General Public License.

[Nov 11, 2004] Freeware List for SPARC

• Solaris 9
  • bash-3.0-sol9-sparc-local.gz Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh) - installs in /usr/local.
• Solaris 8
  • bash-3.0-sol8-sparc-local.gz Bash is an sh-compatible shell that incorporates useful features from the Korn shell (ksh) and C shell (csh) - installs in /usr/local.
• bash-3.0.tar.gz Source Code. [Details]

[Nov 5, 2004] Bash 3.0 now has degugger This is a terse description of the new features added to bash-3.0 since the release of bash-2.05b. As always, the manual page (doc/bash.1) is the place to look for complete descriptions.

cc. The [[ ... ]] command has a new binary `=~' operator that performs extended regular expression (egrep-like) matching.

l. New invocation option: --debugger. Enables debugging and turns on new `extdebug' shell option.

f. HISTCONTROL may now include the `erasedups' option, which causes all lines matching a line being added to be removed from the history list.

j. for, case, select, arithmetic commands now keep line number information for the debugger.

p. `declare -F' now prints out extra line number and source file information if the `extdebug' option is set.

r. New `caller' builtin to provide a call stack for the bash debugger.

t. `for', `select', and `case' command heads are printed when `set -x' is enabled.

u. There is a new {x..y} brace expansion, which is shorthand for {x.x+1, x+2,...,y}. x and y can be integers or single characters; the sequence may ascend or descend; the increment is always 1.

v. New ksh93-like ${!array[@]} expansion, expands to all the keys (indices) of array.

z. New `-o plusdirs' option to complete and compgen; if set, causes directory name completion to be performed and the results added to the rest of the possible completions.

ee. Subexpressions matched by the =~ operator are placed in the new BASH_REMATCH array variable.

gg. New `set -o pipefail' option that causes a pipeline to return a failure status if any of the processes in the pipeline fail, not just the last one.

kk. The `\W' prompt expansion now abbreviates $HOME as `~', like `\w'.

ll. The error message printed when bash cannot open a shell script supplied as argument 1 now includes the name of the shell, to better identify the error as coming from bash.

2. New Features in Readline

a. History expansion has a new `a' modifier equivalent to the `g' modifier for compatibility with the BSD csh.

b. History expansion has a new `G' modifier equivalent to the BSD csh `g'
modifier, which performs a substitution once per word.

c. All non-incremental search operations may now undo the operation of replacing the current line with the history line.

d. The text inserted by an `a' command in vi mode can be reinserted with `.'.

e. New bindable variable, `show-all-if-unmodified'. If set, the readline completer will list possible completions immediately if there is more than one completion and partial completion cannot be performed.

g. History list entries now contain timestamp information; the history file functions know how to read and write timestamp information associated with each entry.

n. When listing completions, directories have a `/' appended if the `mark-directories' option has been enabled.

Not much changed (Score:5, Insightful) by opk (149665) on Thursday July 29, @10:28AM (#9831965)

Doesn't seem to be much changed given the version number increase. [[ =~ ]] can match regexes and it can do zsh style {1..3} expansions. Improved multibyte support too. There were bigger changes in some of the 2.0x updates.

Re:First "zsh rules" post! by Anonymous Coward (Score:3) Thursday July 29, @10:30AM Re:First "zsh rules" post! (Score:5, Informative) by opk (149665) on Thursday July 29, @10:46AM (#9832230) Globs are more powerful: **/*.c will recursively search for .c files: much quicker to type than find. You can match file types: e.g. *(@) will get you symlinks. *(U) gets files owned by you. Syntax for alternation is a lot easier. No @(this|that) or !(*.f). Instead, it is (this|that) and ^*.f Next point is completion. It includes a vast range of definitions so completion works well for lots of commands. The completion system handles completing parts of words so it better handles user@host completion. You get descriptions with completion match listings. Completion also has a really powerful context sensitive configuration system so you can make it work the way you like. It has modules. For running a simple shell script it will actually use less space than bash because it doesn't need to load the line editor and other interactive related code into memory. There is much much more. It takes a while to learn everything but if you just enable the completion functions (autoload -U compinit; compinit) you'll find it better than bash or tcsh from day 1.

Re:Just wondering... (Score:5, Informative) by opk (149665) on Thursday July 29, @11:05AM (#9832448)

Zsh is still the best. Bash developers have different priorities. Bash became the default primarily because it is GNU. Zsh has some ugly but powerful features like nested expansions. The two areas where bash is better than zsh is multibyte support and POSIX compliance. Much of that was contributed by IBM and Apple respectively. But if you use the shell a lot, you'll find zsh does a lot of things better. The completion is amazing. And when it isn't emulating sh/posix, it fixes some of the broken design decisions (like word splitting of variables) which saves you from doing stupid things. The FSF actually does development in a very closed manner when it can (the gcc egcs split was partly because of this). Bash is a good example of this. That perhaps a good thing because it is probably good that bash doesn't get some of zsh's nasty (but powerful) features. And if zsh didn't exist, bash might have been forked by now. If you care about your shell, you'll find much more of a community on the zsh lists than the spam filled bug-bash list. You can't even get at alpha releases of bash without being one of the chosen few.

Can arrow key history be like Matlab's? (Score:3, Interesting) by dara (119068) on Thursday July 29, @10:54AM (#9832323)

I read the announcement and it mentions "History traversal with arrow keys", but what I would really like doesn't seem to be mentioned (but perhaps it is possible with bash-2.05, I'm not much of a shell expert). In Matlab, the up-arrow key searches the history for commands that match all the characters on the line. No characters and it acts like a normal bash arrow, if "figure, plot" is at the beginning of the line, it will quickly scroll through all plotting commands that have been entered at the shell. Any idea if this is possible? Dara Parsavand

This discussion has been archived. No new comments can be posted. Bash 3.0 Released | Log in/Create an Account | Top | 507 comments | Search Discussion Threshold: -1: 507 comments 0: 485 comments 1: 374 comments 2: 270 comments 3: 85 comments 4: 58 comments 5: 39 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way. Re:Can arrow key history be like Matlab's? (Score:2) by Atzanteol (99067) on Thursday July 29, @11:10AM (#9832500) (http://www.edespot.com/~amackenz/) Try 'ctrl+r'. Not *exactly* what you're looking for, but it lets you search through your history. i.e. on an empty line hit ctrl+r, then start typing. [ Parent ] It's not necessary to start on an empty line [n/t] by piranha(jpl) (Score:1) Thursday July 29, @07:25PM Re:Can arrow key history be like Matlab's? (Score:3, Informative) by Anonymous Coward on Thursday July 29, @12:38PM (#9833770) cat >> ~/.inputrc "\e[A": history-search-backward "\e[B": history-search-forward ^D

Re:Can arrow key history be like Matlab's? (Score:1, Informative) by Anonymous Coward on Thursday July 29, @01:17PM (#9834391)

Here you are,put this in .inputrc: "\e[6~": history-search-forward "\e[5~": history-search-backward and use page-up pagge-down to search I can live whithout it since 4dos

Autocompletion like W2K? (Score:2) by tstoneman (589372) on Thursday July 29, @01:12PM (#9834316)

I like bash, but the one thing that it doesn't support (out-of-the-box anyway) is auto-completion a la W2K. In NT, when you hit tab, you can cycle through all the words that can complete the letters you typed... on bash, it shows you a list. Is there a way to make bash behave more like W2K in this sense?

bash completion getting better (Score:3, Informative) by AT (21754) on Thursday July 29, @11:08AM (#9832478)

The completion ability of bash has been steadily improving. There is a nice script here [caliban.org] that sets up a lot of good completion rules for bash.

Re:First "zsh rules" post! (Score:2) by Just Some Guy (3352) <`kirk+slashdot' `at' `strauser.com'> on Thursday July 29, @05:30PM (#9837797) (http://subwiki.honeypot.net/ | Last Journal: Monday September 27, @09:09AM)

That's just... I mean... Wow. Really. I just patched my .zshenv with - export SSH_AUTH_SOCK=$(find 2>/dev/null /tmp -maxdepth 2 -type s -user $USER -regex '/tmp/ssh-.*/agent\..*') + export SSH_AUTH_SOCK=$(echo /tmp/ssh-*/agent.*(=UN)) That's sweet. Thanks for the pointer! The more I learn about zsh, the more I love it.

Re:First "zsh rules" post! (Score:1) by sorbits (516598) on Saturday July 31, @01:09PM (#9853305) (http://macromates.com/)

I will certainly give it a try then! Until now I have sticked with tcsh for one single reason: history substition [go.dlr.de]! Basically it lets me insert text from my history (including the current line) using few symbols (e.g. !$ is the last argument of the previous line) -- it's extremely powerful, e.g. it allows to search in the history and can do substitutions in results, or head/tail for paths etc. I use it a lot to keep down the number of characters I need to type, and I have even assigned hotkeys to some of the substitutions I use the most. This is really the make-or-break feature for wether or not I want to use a shell, so I really hope zsh has something similar!?!

Re:First "zsh rules" post! (Score:5, Informative) by Just Some Guy (3352) <`kirk+slashdot' `at' `strauser.com'> on Thursday July 29, @10:50AM (#9832279) (http://subwiki.honeypot.net/ | Last Journal: Monday September 27, @09:09AM)

Bigs ones for me: A sane auto-completion system. That is, "cvs <tab>" gives a list of all of the commands that cvs understands. "cvs -<tab>" (same as above but tabbing after typing "-") gives a list of all of the options that cvs understands. These are good things. Now, in fairness, bash also has a command completion library. Unfortunately, it's implemented as a huge set of Bash functions. In zsh, "set|wc" returns 179 lines. In bash, "set|wc" returns 3,961 lines. The net effect is that zsh's system is noticeably faster and less polluting to the local environment. Modules. Wrappers for TCP connections, a built-in cron thingy, and PCRE are all loadable modules to do tricky things easily. Lots of pre-defined things. Load the "colors" and "zsh/terminfo" modules and you get defined associative arrays like $fg, which emits terminal-appropriate escape codes to set the foreground color of printed text. The command "echo ${fg[red]}red text${fg[default]}normal text" prints "red text" in red, and "normal text" in your default color. Bash is a good shell, and I have nothing bad to say about it. However, zsh seems to have been designed from the ground up by power users and for power users. I absolutely love it and everyone that I've given a example config file to (to get them running with little hassle) has permanently switched.

Re:First "zsh rules" post! (Score:5, Informative) by Just Some Guy (3352) <`kirk+slashdot' `at' `strauser.com'> on Thursday July 29, @11:21AM (#9832638) (http://subwiki.honeypot.net/ | Last Journal: Monday September 27, @09:09AM)

As the maintainer of FreeBSD's bash-completion [freshports.org] port, I'm reasonably familiar with it. Yes, it's approximately as powerful as zsh's completion module. Still, have you ever looked at it? It's a giant set of defined functions and glue. Seriously, get to a bash prompt and type "set" to see all of the things that've been stuffed into your shell's namespace. Now, try that with zsh and be pleasantly surprised. As I said in another post, a big side effect is that zsh's completions seem to be much faster than bash's. That alone is worth the price of admission for me.

Re:Dear Apple haters... (Score:5, Informative) by Jahf (21968) on Thursday July 29, @10:58AM (#9832361) (Last Journal: Thursday August 05, @03:55PM)

Believe it or not, -most- of the large companies that use GPL'ed tools give back to the community. Apple has done numerous fixes, not just on BASH. Sun (disclaimer: for whom I work) has done -tons- of work on GNOME, Mozilla and don't forget Open Office (just to name a few). IBM works on many projects and gives back ... plus contributing all new things like JFS. All the distro makers like Red Hat, Novell, etc give back tons. Each of those companies pay engineers to fix pieces not done in Open Source projects as well as to extend them for their customers. The patches are covered under GPL just like the main code, and these companies know it and yet knowingly dedicate serious money and hours to these projects. And then they satisfy the GPL by putting them out on source CDs or submitting them back to the main projects. The big problem for getting submitted code accepted is that these companies are usually fixing and developing on a codebase that is aging. For instance, Sun did numerous I18N fixes for GNOME 2.6, but by the time they were ready the main GNOME organization had moved on to 2.8. That means there is a disconnect between the two and the changes have to be ported forward before they will hit the main code branch. The same problem can happen with kernel patches and just about any other codebase that changes versions so quickly. Sorry, you were doing the good thing and pointing out Apple's contributions. But so many people think these companies violate the GPL (in spirit if not in law) when they are very large contributors to open source. Sure, some do, and the community usually find out about it and shame them into minimal compliance (Linksys and Sveasoft come to mind after my delving into alternate WRT54G firmwares last night), but generally speaking the big companies have been a good part of the community.

Re:On the list of changes: (Score:5, Informative) by Prowl (554277) on Thursday July 29, @11:12AM (#9832526)

GNU or Unix would seem to be the most appropriate bash has been around since 1989 (according to copywrite on man page). Linux 1.0 came around 5 years later. The editors should know better, unless they're intentionally trying to piss off RMS

Looks great, but prefer Ash for scripts (Score:3, Interesting) by Etcetera (14711) * <<cleaver> <at> <rohan.sdsu.edu>> on Thursday July 29, @10:41AM (#9832171) (http://www-rohan.sdsu.edu/~cleaver/software/)

Looks like a nice Unicode-savvy release that should help with dealing with international languages at the command line. And yay to Apple for giving back (again). When will people finally accept that Apple is indeed helping out the OSS community through GCC, bash, and other tools...? Kind of off-topic, but for speed purposes in scripts that have to run fast, I find nothing better or more convenient than Ash, especially on systems where /bin/sh is a symlink to /bin/bash. Does anyone know any history on this shell? Is it a clone of the original bourne shell or of bash? I can't seem to find anything useful on Google ...

Re:Looks great, but prefer Ash for scripts (Score:2) by mihalis (28146) on Thursday July 29, @10:52AM (#9832301) (http://www.mihalis.net)

As I understand it, ash was written by Kenneth Almquist. I used to see his name on some of the Ada related mailing lists and newsgroups.

Re:Looks great, but prefer Ash for scripts (Score:2, Informative) by Stephen Williams (23750) on Thursday July 29, @11:46AM (#9832931) (http://nysa.cx/journal/ | Last Journal: Thursday December 05, @05:02AM)

Ash (or dash, as it's called nowadays) is a Linux port of NetBSD's /bin/sh. It's a POSIX shell with separate lineage from bash. http://gondor.apana.org.au/~herbert/dash/ It's /bin/sh on my system too. Faster and smaller than bash; watch those configure scripts fly! -Stephen

Some people don't agree. (Score:2) by emil (695) on Thursday July 29, @12:48PM (#9833940) (http://rhadmin.org/)

Ash appears to consume large amounts of memory, and some people in BSD circles have serious objections to it. See the discussion here [undeadly.org] (scroll down a bit into the postings). I don't have an opinion on the issue one way or another.

And can I set up bash so I can, for instance, move from rc2.d to rc3.d by typing

$ cd 2 3

[May 16, 2004] freshmeat.net Project details for BASH Debugger

BASH Debugger provides a patched BASH that enables better debugging support as well as improved error reporting. It also contains the most comprehensive source code debugger for BASH that has been written. It can be used as a springboard for other experimental features (such as a timestamped history file), since development is maintained openly and developers are encouraged to participate.

• Google Directory - Computers Software Operating Systems Unix Shell bash

• Freeware for Solaris -- downloadable version of bash for Solaris on SPARC and Intel

• Solaris 9 Software companion disk

• Solaris 8 Software companion disk - Download
• The Bourne-Again Shell -- bash homepage
• Bash Features -- explained from what shell each feature originated and how it was extended and integrated. Recommended.
• Bash Prompt HOWTO
• BASH Programming - Introduction HOW-TO
• Bash Reference Manual - Table of Contents -- Edition 2.2, for bash Version 2.02. 1 April 1998
• Bourne Again Shell (bash)
• Bash Features - Table of Contents
• Bash Features
• Bash FAQ [another mirror]
• Bash(1) manual page
• Bash Features - Keyboard Macros

Reference

Things bash has or uses that ksh88 does not:

long invocation options

[-+]O invocation option

`!' reserved word

arithmetic for command: for ((expr1 ; expr2; expr3 )); do list; done

posix mode and posix conformance

command hashing

tilde expansion for assignment statements that look like $PATH

process substitution with named pipes if /dev/fd is not available

the ${!param} indirect parameter expansion operator

the ${!param*} prefix expansion operator

the ${param:offset[:length]} parameter substring operator

the ${param/pat[/string]} parameter pattern substitution operator

variables: BASH, BASH_VERSION, BASH_VERSINFO, UID, EUID, SHLVL,

TIMEFORMAT, HISTCMD, HOSTTYPE, OSTYPE, MACHTYPE,

HISTFILESIZE, HISTIGNORE, HISTCONTROL, PROMPT_COMMAND,

IGNOREEOF, FIGNORE, INPUTRC, HOSTFILE, DIRSTACK,

PIPESTATUS, HOSTNAME, OPTERR, SHELLOPTS, GLOBIGNORE,

GROUPS, FUNCNAME, histchars, auto_resume

prompt expansion with backslash escapes and command substitution

redirection: &> (stdout and stderr)

more extensive and extensible editing and programmable completion

builtins: bind, builtin, command, declare, dirs, echo -e/-E, enable,

exec -l/-c/-a, fc -s, export -n/-f/-p, hash, help, history,

jobs -x/-r/-s, kill -s/-n/-l, local, logout, popd, pushd,

read -e/-p/-a/-t/-n/-d/-s, readonly -a/-n/-f/-p,

set -o braceexpand/-o histexpand/-o interactive-comments/

-o notify/-o physical/-o posix/-o hashall/-o onecmd/

-h/-B/-C/-b/-H/-P, set +o, suspend, trap -l, type,

typeset -a/-F/-p, ulimit -u, umask -S, alias -p, shopt,

disown, printf, complete, compgen

`!' csh-style history expansion

POSIX.2-style globbing character classes

POSIX.2-style globbing equivalence classes

POSIX.2-style globbing collating symbols

egrep-like extended pattern matching operators

case-insensitive pattern matching and globbing

`**' arithmetic operator to do exponentiation

redirection to /dev/fd/N, /dev/stdin, /dev/stdout, /dev/stderr

arrays of unlimited size

Things ksh88 has or uses that bash does not:

tracked aliases (alias -t)

variables: ERRNO, FPATH, EDITOR, VISUAL

co-processes (|&, >&p, <&p)

weirdly-scoped functions

typeset +f to list all function names without definitions

text of command history kept in a file, not memory

builtins: alias -x, cd old new, fc -e -, newgrp, print,

read -p/-s/-u/var?prompt, set -A/-o gmacs/

-o bgnice/-o markdirs/-o nolog/-o trackall/-o viraw/-s,

typeset -H/-L/-R/-Z/-A/-ft/-fu/-fx/-l/-u/-t, whence

using environment to pass attributes of exported variables

arithmetic evaluation done on arguments to some builtins

reads .profile from $PWD when invoked as login shell

Implementation differences:

ksh runs last command of a pipeline in parent shell context

bash has brace expansion by default (ksh88 compile-time option)

bash has fixed startup file for all interactive shells; ksh reads $ENV

bash has exported functions

bash command search finds functions before builtins

bash waits for all commands in pipeline to exit before returning status

emacs-mode editing has some slightly different key bindings

Bash Scripting

FAQs

[gnu.bash.bug] BASH Frequently-Asked Questions (FAQ version 3.29)

FAQ This is the Bash FAQ, version 3.29, for Bash version 3.0.

Readline

Bash Reference Manual Readline Init File

Although the Readline library comes with a set of Emacs-like keybindings installed by default, it is possible to use a different set of keybindings. Any user can customize programs that use Readline by putting commands in an inputrc file, conventionally in his home directory. The name of this file is taken from the value of the shell variable INPUTRC. If that variable is unset, the default is `~/.inputrc'.

When a program which uses the Readline library starts up, the init file is read, and the key bindings are set.

In addition, the C-x C-r command re-reads this init file, thus incorporating any changes that you might have made to it.

8.3.1 Readline Init File Syntax

Syntax for the commands in the inputrc file.

8.3.2 Conditional Init Constructs

Conditional key bindings in the inputrc file.

8.3.3 Sample Init File

An example inputrc file.

etc/inputrc

etc/inputrc deals with the mapping of the keyboard for certain situations. This file is the start-up file used by readline - the input related library used by Bash and most other shells.

For more information see info bash -- Node: Readline Init file as well as info readline. There is a lot that can be done with this one rc file.

The following is a base /etc/inputrc along with comments to explain what the various options do.

Please note that comments can not be on the same line as commands in inputrc.

# Begin /etc/inputrc # Make sure we don't output everything on the 1 line set horizontal-scroll-mode Off # Enable 8bit input set meta-flag On set input-meta On # Turns off 8th bit stripping set convert-meta Off # Keep the 8th bit for display set output-meta On # none, visible or audible set bell-style none # All of the following map the escape sequence of the # value contained inside the 1st argument to the # readline specific functions "\eOd": backward-word "\eOc": forward-word # for linux console "\e[1~": beginning-of-line "\e[4~": end-of-line "\e[5~": beginning-of-history "\e[6~": end-of-history "\e[3~": delete-char "\e[2~": quoted-insert # for xterm "\eOH": beginning-of-line "\eOF": end-of-line # End /etc/inputrc

Global values are set in /etc/inputrc. Personal user values as are set in ~/.inputrc. The ~/.inputrc file will override the global settings file. The previous page sets up Bash to use /etc/inputrc by default. If you want your system to use both, it might be a good idea to place a default .inputrc into the /etc/skel directory for use with new users.

The default behavior of the keyboard often leaves a lot to be desired. It is actually readline that handles this. Readline is a separate package that handles command line interfaces, providing the command history and filename completion, as well as some advanced line editing features. It is compiled into bash. By default, readline is configured using the file .inputrc in your home directory. The bash variable INPUTRC can be used to override this for bash.

Once bash has read the system-wide configuration file, it looks for your personal configuration file. It checks in your home directory for .bash_profile, .bash_login and .profile. It runs the first one of these it finds. If you want to change the way bash behaves for you, without changing the way it works for others, do it here. For example, many applications use environment variables to control how they work. I have the variable EDITOR set to vi so that I can use vi in Midnight Commander (an excellent console based file manager) instead of its editor.

Bash Config Files

How Bash executes startup files.

For Login shells (subject to the -noprofile option):

On logging in:
If `/etc/profile' exists, then source it.

If `~/.bash_profile' exists, then source it,
else if `~/.bash_login' exists, then source it,
else if `~/.profile' exists, then source it.

On logging out:
If `~/.bash_logout' exists, source it.

For non-login interactive shells (subject to the -norc and -rcfile options):
On starting up:
If `~/.bashrc' exists, then source it.

For non-interactive shells:
On starting up:
If the environment variable `ENV' is non-null, expand the variable and source the file named by the value. If Bash is not started in Posix mode, it looks for `BASH_ENV' before `ENV'.

So, typically, your `~/.bash_profile' contains the line
`if [ -f `~/.bashrc' ]; then source `~/.bashrc'; fi' after (or before) any login specific initializations.

If Bash is invoked as `sh', it tries to mimic the behavior of `sh' as closely as possible. For a login shell, it attempts to source only `/etc/profile' and `~/.profile', in that order. The `-noprofile' option may still be used to disable this behavior. A shell invoked as `sh' does not attempt to source any other startup files.

When Bash is started in POSIX mode, as with the `-posix' command line option, it follows the Posix 1003.2 standard for startup files. In this mode, the `ENV' variable is expanded and that file sourced; no other startup files are read.

My .bashrc can be found here.

My .bash_profile can be found here.

.inputrc (readline)--

Although the Readline library comes with a set of Emacs-like key bindings installed by default, it is possible that you would like to use a different set of keybindings. You can customize programs that use Readline by putting commands in an "init" file in your home directory. The name of this file is taken from the value of the shell variable `INPUTRC'. If that variable is unset, the default is `~/.inputrc'.

When a program which uses the Readline library starts up, the init file is read, and the key bindings are set.

In addition, the `C-x C-r' command re-reads this init file, thus incorporating any changes that you might have made to it.

Conditional Init Constructs within readline

Readline implements a facility similar in spirit to the conditional compilation features of the C preprocessor which allows key bindings and variable settings to be performed as the result of tests. There are three parser directives used.

`$if'	The `$if' construct allows bindings to be made based on the editing mode, the terminal being used, or the application using Readline. The text of the test extends to the end of the line; no characters are required to isolate it.
`mode'	The `mode=' form of the `$if' directive is used to test whether Readline is in `emacs' or `vi' mode. This may be used in conjunction with the `set keymap' command, for instance, to set bindings in the `emacs-standard' and `emacs-ctlx' keymaps only if Readline is starting out in `emacs' mode.
`term'	The `term=' form may be used to include terminal-specific key bindings, perhaps to bind the key sequences output by the terminal's function keys. The word on the right side of the `=' is tested against the full name of the terminal and the portion of the terminal name before the first `-'. This allows SUN to match both SUN and SUN-CMD, for instance.
`application'	The APPLICATION construct is used to include application-specific settings. Each program using the Readline library sets the APPLICATION NAME, and you can test for it. This could be used to bind key sequences to functions useful for a specific program.
`$endif'	This command terminates an `$if' command.
`$else'	Commands in this branch of the `$if' directive are executed if the test fails.

The following command adds a key sequence that quotes the current or previous word in Bash:
$if bash
# Quote the current or previous word
"\C-xq": "\eb\"\ef\""
$endif

My .inputrc file is here

Last update by Hermann Heimhardt on October 7, 2001

BASH inputrc Function Binding to Key Ignored

---

From:	William Bloom
Subject:	BASH inputrc Function Binding to Key Ignored
Date:	Thu, 7 Jun 2001 21:56:02 -0700 (MST)

---

I have built BASH 2.05.0(1)-release from source for Solaris
8 as well as FreeBSD 4.3 and have observed a difference from
BASH 2.04 in the handling of the TAB keybinding when 'vi'
editing mode is in use with a POSIX mode BASH session.
I've not seen comments about this in the archive, and the
new behavior continues even after I've applied all patches
from the BASH homepage.  I also don't see comments in the
changelog that seem relevant (perhaps I've missed it).

As an example, suppose  I have a very simple inputrc file as
follows...

        TAB: complete
        C-b: complete-into-braces

...as part of a profile that contains a 'set -o vi'.  The
login shell is /usr/local/bin/sh (a link to BASH) in order
to have a POSIX session.  The above inputrc is simply
intended to let TAB have the same completion behavior to
which some of my users are accustomed from non-POSIX BASH
use.

I find that in this case, the 'C-b' binding is honored but
the TAB binding is ignored.  -After- the session is started,
the TAB binding may be enabled using 'bind -f .inputrc', at
which time the TAB binding is not ignored.

Stranger yet, if the account is changed to use
/usr/local/bin/bash as the login shell, then the session
login now honors the TAB binding.  If the session switches
to POSIX mode (set -o posix) after login, however, then the
TAB binding automagically disappears (although the C-b binding
remains).

Is this behavior related to POSIX compliance, which (I
believe) does not call for TAB to be bound?  Are those users
who want POSIX mode and vi-style command line editing, but
yet aren't ready to give up their accustomed TAB-complete
binding, going to have to have an explicit...

        bind 'TAB: complete'

...to their login profile as of 2.0.5?


Bill

Lee D. Rothstein - Re remapping Cygwin 'bash' readline functions to PC keys

• From: "Lee D. Rothstein" <lee at veritech dot com>
• To: john mapoles <jmapoles at yahoo dot com>, cygwin at Cygwin dot com
• Date: Thu, 20 Feb 2003 12:10:51 -0500
• Subject: Re: remapping Cygwin 'bash' readline functions to PC keys
• References: <[email protected]>

John, thanks for the <C-V> heads up! Others had
suggested, variations of 'cat < foo' and 'od -c'. (The
former I got to work, the latter remains a mystery.)
Your solution, besides being the most straight-forward,
is also a great tool to have around. Apparently, it's a
feature of Cygwin, or 'bash', since it doesn't work in
a naked 'cmd.exe' window. I'll be sure to add it to my
documentation.
 

Unfortunately the key combos I'm trying to map to
are: <^-->> and <^-<-> (control- and the right and left
arrow keys). It turns out that the character string
outputs for both the:
 

* naked key
* shift - and the naked key
* control- and the naked key

are all the same.

Actually, I no longer consider these to be KIDs; these
are the character string graphemic outputs of hitting
the key. I'll continue to reserve "KIDs" for when one
represents these [and the key isomorphisms]
with '/e...', 'C-...', etc. "notation".
 

Apparently (?), the only way to discriminate among these
three alternatives is with Scan Codes. Apparently, all
the -x-ish stuff I've used (Microemacs, Thompson shell
command line editing) that can discriminate among the
three alternatives all use Scan Codes (?).
 

 - Any way to map to Scan Codes to 'bash' 'readline'
   functions under Cygwin?
   + Or to key "names" like: '<CTRL-left-arrow>',
     '<CTRL-HOME>'
 - Any interest among Cygwin developers in adding
   this?
 

>At 2003-02-19 08:02 AM -0800, John Mapole wrote:
...
>You can build your own KID table. Once at the cygwin
>prompt you can type <C-V>, that's control-V, followed
>by the key.  On my machine, if I type <C-V><INSERT>, I
>see "^[[2~".  This is the same as "\e[2~".
>
>Why these mapping are like this relates to how windows
>maps them and then how cygwin maps them.  Something I
>am now very clear on.
>
>Hope this helps some.
>
>John Mapoles
>
>--- "Lee D. Rothstein" <lee at veritech dot com> wrote:
...
>> Q1 -- When you remap a 'bash' Edit Mode function in
>> .inputrc, it looks like this:
>>
>> "\e[3~":      delete-char # DEL key
>>
>> The entity in double quotes ("\e[3~"), I'm calling
>> the "key ID (KID)". In the above '.inputrc' declaration,
>> the function 'delete-char' being remapped from its
>> default key assignment to the KID -- "\e[3~" -- the
>> <DEL> key.
>>
>> What are the KIDs of the following IBM PC keys
>> (specified below with facsimiles of the key caps
>> contained in angle brackets -- '<...>')?
>>
>> Cursor control key pad
>> ----------------------
>> <HOME>
>> <END>
>> <left-arrow>
>> <right-arrow>
>> <PAGE_UP>
>> <PAGE_DOWN>
>> <INSERT>
>>
>> Numeric pad
>> -----------
>> <->
>> <+>
>> <ENTER>
>> </>

I should have included in the above lists, all variations
of the above with the control, alt and shift keys.

>> In general, I'd like a table that maps the KIDs for all
>> 104 keys on the keyboard I use. Or, better still, is
>> there a way to use scan codes?
>>
>> (Incidentally, what makes finding a table of these
>> KIDs so difficult is the failure of the documentation
>> to assign this concept a unique, or even a consistent
>> word.)
>>
>> Q2
>> --
>>
>> Is there a way to make the <INSERT> key a toggle
>> between the insert and overwrite modes of 'bash'
>> edit mode?
>>
>> I used to have these figured out for 'Microemacs',
>> but that was half a lifetime ago, for me, & Microemacs
>> supported scan codes, if I remember correctly.

--
Lee D. Rothstein -- lee at veritech dot com
VeriTech -- 603-424-2900
7 Merry Meeting Drive
Merrimack, NH 03054-2934

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Why can't solaris be more like linux...

• Previous message: Why can't solaris be more like linux...
• Next message: A group statement on SCO
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I agree with Nick on this one. I don't know about the inputrc stuff but
I do know that in the past, I would set my TERM to VT220 then all my
keys worked correctly.  Try:
% export TERM=VT220


On Fri, 2003-05-16 at 12:23, Nicholas Leippe wrote:
> On Friday 16 May 2003 10:14 am, you wrote:
> > I've been given access to a bunch of solaris 8 boxen here at work
> > lately, and i'm finding it difficult to move around in it because of
> > shell differences... i guess i've always taken the default setups of any
> > linux distro i've ever tried for granted.  On the solaris box, I've had
> > my shell set to BASH as that is my preference... but i still get "^?"
> > characters while trying to backspace in vi and from ftp... and i get "~"
> > when trying to "delete".  Anyone know of a quick way to get the shell
> > setup "correctly"?
> 
> Trying creating a ~/.inputrc file (see READLINE section in the bash man page).
> My global inputrc in linux (/etc/inputrc) is:
> 
> set meta-flag on
> set input-meta on
> set convert-meta off
> set output-meta on
> "\e0d": backward-word
> "\e0c": forward-word
> "\e[h": beginning-of-line
> "\e[f": end-of-line
> "\e[1~": beginning-of-line
> "\e[4~": end-of-line
> "\e[5~": beginning-of-history
> "\e[6~": end-of-history
> "\e[3~": delete-char
> "\e[2~": quoted-insert
> "\e[g": beginning-of-line
> "\e[e": beginning-of-line
> "\e[H": beginning-of-line
> "\e[F": end-of-line
> "\e[G": beginning-of-line
> "\e[E": beginning-of-line
> "\e[s": beginning-of-line
> DEL: backward-delete-char
> 
> 
> Some of that came from Redhat 6.2's /etc/inputrc.  You could also try copying 
> it from whatever distro you have installed nearby.  Also, check your TERM 
> variable.  When that's not correct, some things can get really wierd. (eg it 
> shouldn't be 'xterm' when in the console)
> 
> 
> Nick

-- 
Matthew Frederico
Unwired Networks
[email protected]
http://www.unwirednetworks.com

• Subject: Re: [ale] Automating vi-style history editing in bash
• From: "Fulton Green" <[email protected]>
• Date: Wed, 1 Mar 2000 18:06:19 -0500
• In-Reply-To: [email protected]

---

On Wed, Mar 01, 2000 at 04:55:31PM -0500, David S. Jackson wrote:
> On Wed, Mar 01, 2000 at 03:09:22PM -0500 Fulton Green <[email protected]> wrote:
> > I know how to set up bash to let me edit previous commands vi-style by typing
> > set -o vi
> > or
> > export EDITOR=vi
>
> These two things are not really the same at all. Your shell's
> editing mode (if it is bash) is set with set -o vi or set -o
> emacs. Or you can emulate yet another editor by setting the
> $readline variable in .inputrc.
>
> However, the $EDITOR variable is something else. Applications
> check if this variable exists if no editor is defined by default
> for that application. You can set emacs editing mode for the
> shell and set the $EDITOR variable to vi. No problem.

True for bash, and you can do this in ksh as well. However, ksh also examines
$EDITOR if the readline mode hasn't been set with 'set -o vi|emacs'. At least
this is the behavior on Solaris 2.6, whose Korn shell doesn't appear to do
the inputrc thing. My apologies for confusing Korn's behavior with bash's.

> > at the command line. My problem: under Red Hat 6.1, I can't seem to get
> > either of these to have an effect when I put either of them in .bash_profile
> > or .bashrc
>
> Again, the statements don't mean the same thing. But just open
> an Xterm (or whatever) and type set -o vi at the command prompt.

And that works for me.

> > In fact, doing the "set" command in .bashrc ensures that I won't
> > even be able to *manually* set the mode from the command line.
>
> This shouldn't be true. Using the set command shouldn't prohibit
> you from 'unsetting' the editing mode. I normally use emacs mode

It *is* true in my circumstance, but it's iff the 'set -o vi' is executed in
my .bashrc file. And at this point, I should mention that I didn't notice any
problem until I upgraded Red Hat to 6.0. I also confirmed the problem on a
fresh RH 6.1 box. I'm going to change the main runlevel in /etc/inittab from
5 to 3 (i.e., don't start out in an X server) to see if that affects anything.

> Are you using an .inputrc?

I'm not. That could very well be the problem if the global inputrc has
trash, as pointed out by earlier emails. I don't have the computer in question
in front of me at the moment, but I could almost swear that RH 6.0 or 6.1 did
away with /etc/inputrc . Or was that /etc/skel/.inputrc ?

Thanks for the help,

Fulton Green
http://www.FultonGreen.com/

Random Findings

Re Suggestions for corrections to executable.el - use of PATHEXT

From: "Eli Zaretskii" <[email protected]>

> First, I'm not sure we should look at PATHEXT.  That variable is AFAIK
> looked at by the shell, so if we want Emacs behave _exactly_ like the
> shell does, we should at least look at the value of SHELL and/or
> ComSpec (and COMSPEC for older systems).  I mean, what if the user's
> shell is Bash, which AFAIK doesn't look at PATHEXT at all?  And if the
> shell is COMMAND.COM, then ".cmd" should not be in the list.  Etc.,
> etc.

PATHEXT is looked at by cmd.exe (the default shell on the NT hereditary
line). I do not know if it is used by command.com (the default shell on the
95 line) but I doubt it. When I tested now I found that the Run entry in
Windows Start menu honor the default extensions for PATHEXT (.com, .exe.,
.bat, .cmd). It does not however not recognize .pl which I have in my
PATHEXT (cmd.exe recognize it). I am using NT4 when testing this.

So perhaps not even ms windows is consistent here. What seems clear however
is that the main purpose of PATHEXT is as far as I can see to make it easier
for the user when entering a command interactively. The user may for example
type "notepad" instead of "notepad.exe".

PATHEXT is set by the user and expresses the users wish to type less. It
seems reasonable to use PATHEXT for this purpose in Emacs too. The variable
executable-binary-suffixes is (if I understand this correctly) used for this
purpose by executable-find. This is however not clearly expressed in the
documentation.

A note: w32-shell-execute does something quite different. It calls the ms
windows API ShellExecute to do the action associated with a certain "verb"
on a file type (on windows this means file extension). Typical verbs are
"open" and "print". Windows Explorer uses this.

Having said all this I just want to say that I regret that I took this issue
up without looking closer at the problem.

- Lennart

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019