Re: exec, redirections and variable expansions
mike bakhterev a écrit : > > Description: > Something is wrong with variable substitution in the exec invocation. > When i try to close file descriptor whose number is in variable X with > command: > > exec $X>&- I think the operator is 2> as a whole; you cannot split the two characters. Operators are parsed before parameter expansion. In other words, what you are trying to do is a bit like: I=i F=f # Does not work either! $I$F true; then echo foo; fi You need eval: eval "$I$F true; then echo foo; fi" # Works eval "exec $X>&-" # Works
Re: Selecting out of an array
DennisW a écrit :
> Also, don't use ls like this - it's eyes-only.
Here is a demonstration:
touch "filename with spaces"
ARRAY=( $(ls) ) # BUG
for f in "${arr...@]}"; do echo "file: $f"; done
ARRAY=( * ) # OK
for f in "${arr...@]}"; do echo "file: $f"; done
Using 'eval'
This is probably a dumb question; however, I have a question regarding 'eval'. I have seen the following statements: eval $(foo -a -b) and eval foo -a -b Are they equal or are there differences between them, other than how they are written out? Does it make any difference which syntax is used? -- Gerard ger...@seibercom.net |=== |=== |=== |=== | COLLEGE: The fountains of knowledge, where everyone goes to drink.
Re: Using 'eval'
On Tue, Jan 26, 2010 at 1:27 PM, Gerard wrote: > This is probably a dumb question; however, I have a question > regarding 'eval'. > eval foo -a -b eval will execute foo -a -b. > eval $(foo -a -b) foo -a -b will run before eval is executed, the output of foo will replace the $( ). ie if foo -a -b prints "echo hello" then the command executed will be "eval echo hello" which execute echo hello, and it will print hello the difference with or without eval is that the expansion are done 2 times: var=foo foo=bar;echo '$'$var after the expansion $var is replace by it's value and the command executed: echo '$'foo which prints '$foo' var=foo foo=bar;eval echo '$'$var after the expansion $var is replace by it's value and the command executed: eval echo $foo eval will do the expansion quote removal a second time and the command executed by eval will be: echo bar which prints "bar"
Re: Using 'eval'
Gerard a écrit : > This is probably a dumb question; however, I have a question > regarding 'eval'. If you know other programming languages, then it helps to consider "eval" as a technique that generates code at run time (and runs it immediately).
Colored command completion
I'm wondering if it is possible to color the files shown by command completion (i.e. after typing ). The color scheme can be of the same as the one used in "ls --color=auto". By this way, it is easier to see what the type of the file is.
Re: exec, redirections and variable expansions
On 1/25/10 8:32 AM, mike bakhterev wrote:
> Bash Version: 4.0
> Patch Level: 35
> Release Status: release
>
> Description:
> Something is wrong with variable substitution in the exec invocation.
> When i try to close file descriptor whose number is in variable X with
> command:
>
> exec $X>&-
>
> Bash reports:
>
>exec: NUMBER: not found
The file descriptor number must be a decimal number specifying the fd to
close; it cannot be a word and is not subject to expansion. If you use
`eval', you will get the results you want.
Bash-4.1 introduces a new redirection syntax that does what you want:
exec {X}>&-
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Colored command completion
On 1/26/10 10:36 AM, Peng Yu wrote: > I'm wondering if it is possible to color the files shown by command > completion (i.e. after typing ). The color scheme can be of the > same as the one used in "ls --color=auto". By this way, it is easier > to see what the type of the file is. You mean the list of possible completions? It's not exactly what you asked for, but look at the readline `visible-stats' variable. That produces output in the style of `ls -F'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Argument list too long (how to remove the limit)
2010-01-25, 18:03(-06), Peng Yu:
> I got the following message. Is there a way to configure bash such
> that there is not a limit like this?
>
> /bin/bash: Argument list too long
[...]
That's a limitation of the execve(2) system call on some
operating systems. GNU Hurd and recent versions of Linux are
known not to have that limitation.
It's a limitation on the cumulative size of the arguments and
environment passed to an executed command. The limit varies
between systems.
To work around it, you may have to run several instances of the
same command, with a subset of the argument list each time.
zsh's zargs or xargs or find may come handy.
For instance, instead of:
rm ./*
Try:
find . ! -name . -prune ! -name '.*' -exec rm {} +
Instead of
rm /very/long/path/to/some/directory/*
try:
cd /very/long/path/to/some/directory && rm -- *
Also, as it's a limit on the execve(2) system call, it doesn't
apply to shell builtins. So, if you're using zsh, you could use
the zsh/files module to have most of the stanard file handling
commands builtin:
zmodload zsh/files
rm -- *
--
Stéphane
Re: Colored command completion
2010-01-26, 09:36(-06), Peng Yu:
> I'm wondering if it is possible to color the files shown by command
> completion (i.e. after typing ). The color scheme can be of the
> same as the one used in "ls --color=auto". By this way, it is easier
> to see what the type of the file is.
[...]
A bit off topic here, but note that zsh supports that and can
use GNU ls's configuration as well ($LS_COLORS). zsh is largely
compatible with bash. You can use "compinstall" to configure
the completion, or you could try those settings (they have been
generated by compinstall for me):
(set -C && dircolors -p > ~/.dircolors) 2> /dev/null
eval "$(dircolors -b ~/.dircolors)"
zstyle ':completion:*' completer _expand _complete _ignored _correct
_approximate _prefix
zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}
zstyle ':completion:*' matcher-list '' 'm:{a-z}={A-Z}' 'm:{a-zA-Z}={A-Za-z}'
'r:|[._-]=* r:|=* l:|=*'
zstyle ':completion:*' max-errors 1 not-numeric
zstyle ':completion:*' menu select=2
zstyle ':completion:*' original true
zstyle ':completion:*' prompt 'correct> '
zstyle ':completion:*' select-prompt %SScrolling active: current selection at
%p%s
autoload -U compinit
compinit -i
(you need a relatively recent version of zsh (at least
3.1.5-pws-24, circa 1999) (some OSes like Solaris come with a
very old version of zsh (or at least used to))).
--
Stéphane
Re: building arrays from non array variables using 'array[${#arr...@]}]='
On 1/25/10 6:58 AM, Mart Frauenlob wrote:
> As i came up with this i have to go further ;) ,so i installed bash
> 4.1.2 and your new patch and ran tests again with it and 3.1.17, 4.0.35
> versions.
> Patch seems to be working for return values of '${#arr...@]}'.
> But ${!arr...@]} returns 0 on the declared but unassigned local variable
> - which i think should be the NULL string.
You're right.
> What worries me, is that v4.0.35 behaves weird with a local variable
> declared, as ${#arr...@]} always returns 1 inside the fill() loop.
Why does that worry you? This is what I posted the patch to change.
> Also i noticed, that from bash 4 it looks like the declare builtin
> reacts differently. `declare -p var' on a globally declared but
> unassigned variable returns false, but for the same thing as a local
> variable it returns: `declare -- var=""' (with true as exit status of
> course).
It should return "declare -- var" in the function when used with a local
variable. The minor inconsistency is for two reasons: to shadow any
global copy of the variable, since the normal behavior would be to ignore
it and people expect `declare var' to create a local variable, and to
save a reference to any other attributes, since users expect `declare -i
var' to perform arithmetic evaluation on a variable when it's assigned
a value.
The problem with this is that it leads to other minor inconsistencies,
two of which you found. These will be fixed in the next version of bash.
Thanks for testing these details.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
