edit-and-execute-command (C-xC-e) doesn't use FCEDIT env variable
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux mars.wyplay.int 2.6.26 #25 SMP Thu Aug 14 15:32:39 CEST 2008 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: When I execute edit-and-execute-command realdline command by typing C-xC-e, it seems that bash always launch emacs whatever the setting of FCEDIT env variable. However man bash say the opposite. Repeat-By: $ export FCEDIT=vi $ $ alias emacs=vi $ -- Francis
Re: 'read' primitive
Bob Proulx wrote: > To get the entire line verbatim you would need to use the $REPLY > variable. Or also use IFS= read -r foo < bar -- D.
Odd history clobbering.
I have seen, upon occasion, that my ridiculously long HISTSIZE (10) will be truncated if two bash instances are closed at the same time. Always to 1000 lines. In order to work around this behavior I have a rather icky .bash_logout that uses fuser and gzip to archive the entire history to a new file whenever a shell instance exits. Do any other bash users see history truncation? If you do, aside from working around the issue have you any advice for methods by which this may be further analysed? Or perhaps there is a known remedy.
Re: Odd history clobbering.
"Matthew A. R. Sherian" <[EMAIL PROTECTED]> writes: > I have seen, upon occasion, that my ridiculously long HISTSIZE (10) Do you have set HISTFILESIZE too? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: edit-and-execute-command (C-xC-e) doesn't use FCEDIT env variable
Francis Moreau wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
-mtune=generic
uname output: Linux mars.wyplay.int 2.6.26 #25 SMP Thu Aug 14 15:32:39
CEST 2008 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 3.2
Patch Level: 33
Release Status: release
Description:
When I execute edit-and-execute-command realdline command by typing
C-xC-e,
it seems that bash always launch emacs whatever the setting of
FCEDIT env variable.
However man bash say the opposite.
Good catch. The command executed is actually
fc -e "${VISUAL:-${EDITOR:-emacs}}"
It's the same command for vi and emacs editing modes, though the default
for vi editing mode is `vi' instead of `emacs'. The documentation needs
to be updated, and has for a while, since it's been this way since at
least bash-2.05. Seven years is a long time for this to go unnoticed.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: edit-and-execute-command (C-xC-e) doesn't use FCEDIT env variable
On 8/22/08, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Good catch. The command executed is actually
>
> fc -e "${VISUAL:-${EDITOR:-emacs}}"
>
> It's the same command for vi and emacs editing modes, though the default
> for vi editing mode is `vi' instead of `emacs'. The documentation needs
> to be updated, and has for a while, since it's been this way since at
> least bash-2.05. Seven years is a long time for this to go unnoticed.
hmm why not fixing the command instead ?
VISUAL can be used to visualize a file, so can be set to 'less' for
example. It shouldn't be used if you wand to edit.
I think what is described in the man is fine. And I wanted to
customize FCEDIT to launch emacs in sh-mode, something I can't do with
current command setting.
--
Francis
Bash for Windows
I've ported bash to Windows and would like my changes to be part of the main codebase. Would there be any interest in doing this?
completing dir names for a certain path?
I have a function 'cs' that roughly looks like 'cd /some/prefix/$*', that I would like to have completion for. Any tips? (For some reason, non-trivial completions never seem to want to work for me :-(.) IOW, if /some/prefix has the directories 'foo' and 'bar', I would like: $ cs b ...to complete to... $ cs bar I've tried this and it doesn't work: complete -C 'cd /some/prefix && compgen -d "$@"' cs In fact, this doesn't seem to work either, meaning, generates no completions: complete -C 'compgen -d' cs ...which implies that either the doc fails to explain how to use 'complete -C', or else it just plain doesn't work. Note that compgen works as expected, I just can't get anything to work with 'complete -C'. -- Matthew For great justice!! -- Captain (Zero Wing)
Re: edit-and-execute-command (C-xC-e) doesn't use FCEDIT env variable
Francis Moreau wrote:
On 8/22/08, Chet Ramey <[EMAIL PROTECTED]> wrote:
Good catch. The command executed is actually
fc -e "${VISUAL:-${EDITOR:-emacs}}"
It's the same command for vi and emacs editing modes, though the default
for vi editing mode is `vi' instead of `emacs'. The documentation needs
to be updated, and has for a while, since it's been this way since at
least bash-2.05. Seven years is a long time for this to go unnoticed.
hmm why not fixing the command instead ?
It's not broken.
VISUAL can be used to visualize a file, so can be set to 'less' for
example. It shouldn't be used if you wand to edit.
That isn't the case. In fact, it's exactly the opposite.
The historic use of VISUAL was for the user to set it to his preferred
`visual' (screen-oriented) editor (note the similarity to `vi') while
leaving EDITOR set to, most often, `ed'. It can be set to `less', but
I'm not sure why you'd want to.
These days there's no practical difference between the two.
You might see what `man environ' on your system says. A random Ubuntu
system I have access to reflects the usage as I've described it.
I think what is described in the man is fine. And I wanted to
customize FCEDIT to launch emacs in sh-mode, something I can't do with
current command setting.
I'll consider it as an enhancement request for a future version. You
can, of course, set `VISUAL' to a command that starts emacs in the
desired mode.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: completing dir names for a certain path?
Matthew Woehlke wrote: I have a function 'cs' that roughly looks like 'cd /some/prefix/$*', that I would like to have completion for. Any tips? (For some reason, non-trivial completions never seem to want to work for me :-(.) Why not write a shell function that prefixes the right directory to the word to be completed, runs compgen, and strips the prefix from the generated list of completions? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Bash for Windows
Hector Chu wrote: I've ported bash to Windows and would like my changes to be part of the main codebase. Would there be any interest in doing this? Tell me more. What makes your port different from the existing ones? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: completing dir names for a certain path?
Chet Ramey wrote:
Matthew Woehlke wrote:
I have a function 'cs' that roughly looks like 'cd /some/prefix/$*',
that I would like to have completion for. Any tips? (For some reason,
non-trivial completions never seem to want to work for me :-(.)
Why not write a shell function that prefixes the right directory to
the word to be completed, runs compgen, and strips the prefix from the
generated list of completions?
Because "for some reason, non-trivial completions never seem to want to
work for me"?
Sigh. Ok, after trying for entirely too long, this seems to be working:
completeme() {
local i=0
while read l; do
COMPREPLY[$((++i))]="$l"
done < <(
cd /some/prefix
w="${COMP_WORDS[1]}"
if [ -n "$w" ]
then compgen -d "$w"
else compgen -d
fi
)
}
complete -F completeme cs
...and yet, seems entirely too difficult.
Why doesn't 'complete -C' work? Why does 'compgen -d ""' produce no
output? Shouldn't it produce the same output as 'compgen -d'?
--
Matthew
For great justice!! -- Captain (Zero Wing)
Re: Bash for Windows
This port uses mingw32 to build, producing a so called native build of bash. The existing code paths are retained (unlike earlier ports), increasing maintainability. Most attempts have difficulty with reconciling the use of fork and exec in the execute code paths. Windows only has a CreateProcess function which allows a fresh child process loaded from an executable to be spawned. The simplest solution I adopted is to copy the data from the parent bash to the child bash over a pipe. This means variables, history etc. The location to jump to is also sent across, so the child can start executing after the 'fork'. To deal with the possibility of the child exec'ing, the parent shell waits for the child to do the exec. The child execs by spawning the new process, piping the PID back to the parent, and then exiting. The parent now has the real PID and can wait on it if needed. In terms of code impact, there is a 1800 line new file, and ifdef'ed code scattered around the other various files. Each change in existing files is very small, around 1-10 lines in each place. 38 files were changed. 2 added. 2008/8/23 Chet Ramey <[EMAIL PROTECTED]>: > Hector Chu wrote: >> >> I've ported bash to Windows and would like my changes to be part of >> the main codebase. Would there be any interest in doing this? > > Tell me more. What makes your port different from the existing ones? > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > Chet Ramey, ITS, CWRU[EMAIL PROTECTED] > http://cnswww.cns.cwru.edu/~chet/ >
Re: Bash for Windows
Hector Chu wrote: In terms of code impact, there is a 1800 line new file, and ifdef'ed code scattered around the other various files. Each change in existing files is very small, around 1-10 lines in each place. 38 files were changed. 2 added. Sure, I'm interested. Send them to me, please. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: completing dir names for a certain path?
Matthew Woehlke wrote:
Because "for some reason, non-trivial completions never seem to want to
work for me"?
Sigh. Ok, after trying for entirely too long, this seems to be working:
completeme() {
local i=0
while read l; do
COMPREPLY[$((++i))]="$l"
done < <(
cd /some/prefix
w="${COMP_WORDS[1]}"
if [ -n "$w" ]
then compgen -d "$w"
else compgen -d
fi
)
}
complete -F completeme cs
...and yet, seems entirely too difficult.
Maybe something like this?
foo()
{
local -a a
PREFIX=/usr/local
builtin cd $PREFIX || {
COMPREPLY=()
return 1
}
a=( $(compgen -d "$2") )
COMPREPLY=( "[EMAIL PROTECTED]/}" )
builtin cd $OLDPWD
}
The difficulty is getting a trailing `/' -- readline won't add it, since
the completions are in a different directory.
Why doesn't 'complete -C' work?
Programmable completion invokes the command specified with -C with three
arguments:
$1 = command name
$2 = word to be completed (possibly null)
$3 = previous word
It's really designed to work with external commands or shell functions
that understand arguments, not command lists. There's no other way for
an external command to get the word to be completed.
Why does 'compgen -d ""' produce no
output? Shouldn't it produce the same output as 'compgen -d'?
Ummm...it does for me.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Bash for Windows
I've ported bash to Windows and would like my changes to be part of the main codebase. Would there be any interest in doing this?
Issue with parameter and command substitution in case statement
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -msse3 -O2 -march=athlon64 -pipe uname output: Linux strythbox 2.6.24.3 #2 Thu Mar 13 10:21:15 EDT 2008 i686 AMD Athlon(tm) 64 Processor 3800+ AuthenticAMD GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: the gnu bash manual indicates: "The syntax of the case command is: case word in [ [(] pattern [| pattern]...) command-list ;;]... esac" and further that: "Each pattern undergoes tilde expansion, parameter expansion, command substitution, and arithmetic expansion." While command substitution and parameter expansion occur, the resulting strings are not parsed in a fashion consistent with the normal behavior. Take, for example, the string "1|2". when used in the form case 2 in \ 1|2) ... the function execute_case_command, in the strmatch line. This line is executed twice, once being a strmatch (2,1) and the other being strmatch (2,2). Obviously the 2,2 is the match. On the other hand, when a variable VAR='1|2' is used (case 2 in $var ... ) the comparison performed is strmatch (2,1|2) which fails. 1|2 is never broken into its components. Repeat-By: #! /bin/bash VAR='1|2' echo test is 'case 2 in $VAR=1|2' case 2 in $VAR) echo good ;; *) echo fail ;; esac echo echo test is 'case 2 in 1|2' case 2 in 1|2) echo good ;; *) echo fail ;; esac echo VAR='2' echo test is 'case 2 in $VAR=2' case 2 in $VAR) echo good ;; *) echo fail ;; esac echo echo test is 'case 2 in 2' case 2 in 2) echo good ;; *) echo fail ;; esac echo echo test is "case 2 in \`echo '1|2'\`" case 2 in `echo '1|2'`) echo good ;; *) echo fail ;; esac echo echo test is 'case 2 in 1|2' case 2 in 1|2) echo good ;; *) echo fail ;; esac
