>Like it or not, POSIX standardized the original bourne shell `` behavior,
>as well as the ksh $() behavior, and the two behaviors are different. Get
>used to it.
Well, thank you for telling me to "get used to it". But I do
not generally obey unreasonable commands.
Now, please tell me how I can
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACH
TYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown'
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='b
ash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
[EMAIL PROTECTED] wrote:
> >Like it or not, POSIX standardized the original bourne shell `` behavior,
> >as well as the ksh $() behavior, and the two behaviors are different. Get
> >used to it.
>
> Well, thank you for telling me to "get used to it". But I do
> not generally obey unreasonable comm
Bob Proulx wrote:
> This is probably not a an optimal solution because this is late night
> time for me but this works:
>
> eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
This also works.
find . -exec grep -q PATTERN {} \; -exec vi {} \;
Bob
___
>
>It is unfortunate that your choice of editor does not accept zero
>terminated strings as filenames because then this would be easy using
>grep's --null option. The problem therefore as I see it is a
>deficiency in the editor capabilities.
>
Oh, so all applications should be adjusted to account
>> This is probably not a an optimal solution because this is late night
>> time for me but this works:
>>
>> eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
>
>This also works.
>
> find . -exec grep -q PATTERN {} \; -exec vi {} \;
>
No it doesn't because it issues a fresh instance of vi per fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 10/29/2006 5:56 AM:
>> This also works.
>>
>> find . -exec grep -q PATTERN {} \; -exec vi {} \;
>>
>
> No it doesn't because it issues a fresh instance of vi per file.
Then use the POSIX-specified:
find . -exec grep
>According to [EMAIL PROTECTED] on 10/29/2006 5:56 AM:
>>> This also works.
>>>
>>> find . -exec grep -q PATTERN {} \; -exec vi {} \;
>>>
>>
>> No it doesn't because it issues a fresh instance of vi per file.
>
>Then use the POSIX-specified:
>find . -exec grep -q PATTERN {} \; -exec vi {} +
>
>Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 10/29/2006 3:39 AM:
> Why is it that word splitting never makes a distinction between
> newlines and space?
Because POSIX, and tradition, say so.
> Because the output of grep -l, and ls, etc are
> clearly newline de
>
>According to [EMAIL PROTECTED] on 10/29/2006 3:39 AM:
>> Why is it that word splitting never makes a distinction between
>> newlines and space?
>
>Because POSIX, and tradition, say so.
>
>> Because the output of grep -l, and ls, etc are
>> clearly newline delimited.
>
>That is a flawed argument
[EMAIL PROTECTED] wrote:
> But, given that find is clever enough to assemble arguments containing
> spaces into an arglist and feeding them to vi, why can't bash?
I find the 'find' solution to be one that I am more attracted to but
if you put it that way I will note that bash has the capabilities.
[EMAIL PROTECTED] wrote:
> >This is probably not a an optimal solution because this is late night
> >time for me but this works:
> >
> > eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
>
> Yes, that works.
> But surely such a grotesque syntax is not really in the spirit
> of concise unix expression
Chacallot Chacallot wrote:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACH
> TYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown'
> -DLOCALEDIR='/usr/share/locale' -DPACKAGE='b
> ash' -DSHE
[EMAIL PROTECTED] wrote:
>> Word splitting is controlled by IFS. Use IFS=$'\n' to only split on
>> newlines.
>>
>> Andreas.
>
> Well, I still dont see any examples. I don't think it is possible even
> using IFS. Even if it does work somehow, it isn't easy or intuitive.
Oh, for pete's sake. Ta
>Oh, for pete's sake. Take a systematic approach, as Andreas suggested.
>First, arrange for the filenames you want to be delimited by newlines.
>Since this is for your own use, and you can more-or-less guarantee that
>there will never be a newline in a filename, that's sufficient. Second,
>arrang
[EMAIL PROTECTED] wrote:
>> Take a look at the approach in the following example script. `recho' is
>> part of the bash distribution; it's built while running the test suite.
>> I used `ls -1' to create a newline-delimited list of filenames.
>>
>> $ cat x3
>> [ -d scratch ] || mkdir scratch
>> cd
>>> $ cat x3
>>> [ -d scratch ] || mkdir scratch
>>> cd scratch
>>> touch 'a b w' 'c d x' 'e f y' 'g h z'
>>>
>>> IFS=$'\n'
>>> recho $(ls -1 *)
>>> $ ../bash-3.2/bash ./x3
>>> argv[1] =
>>> argv[2] =
>>> argv[3] =
>>> argv[4] =
>>>
>>
>> Easier is just:
>>
>> ls -1 *
>>
>> Why not g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 10/29/2006 4:52 PM:
>
> I took a very deep breath and did this from command line:
>
> IFS='\n' vi $(grep -l PATTERN *)
>
> and guess what - it does not work!
That's because you set IFS for the vi, but not for t
>According to [EMAIL PROTECTED] on 10/29/2006 4:52 PM:
>>
>> I took a very deep breath and did this from command line:
>>
>> IFS='\n' vi $(grep -l PATTERN *)
>>
>> and guess what - it does not work!
>
>That's because you set IFS for the vi, but not for the command
>substitution. Break your
>
>That's because you set IFS for the vi, but not for the command
>substitution. Break your result into two commands:
>
>IFS='\n'
>vi $(grep -l PATTERN *)
>
So the IFS setting takes effect immediately after it is seen?
So a newline is needed?
I would have hoped that the IFS was interpreted after
>That's because you set IFS for the vi, but not for the command
>substitution. Break your result into two commands:
>
>IFS='\n'
>vi $(grep -l PATTERN *)
>
But also, if IFS is what it is supposed to be, wouldn't the correct
syntax be:
IFS='\n'
vi
$(grep
-l
PATTERN
*)
Or i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 10/29/2006 5:29 PM:
> But dont variables set on command line apply to everything on
> that line?
Nope. According to 2.9.1 Simple Commands, variable assignments are
deferred until after expansions, which include comma
>
>In other words, IFS only affects the results of expansions, not literal
>text; words, in the sense of the shell grammar, are always delineated by
>unquoted space, tab, and newline, regardless of the IFS setting.
>
Thanks for an excellent explanation.
But maybe IFS really should have been named
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to [EMAIL PROTECTED] on 10/29/2006 6:19 PM:
>
> But maybe IFS really should have been named EFS?
Tradition is hard to break. Yes, even POSIX admits in its rationale
section that the name IFS is somewhat misleading. But shells have
impleme
>
>Messing with shell syntax is not done lightly. It is too late to change
>how `` and $() behave; you will break too many existing scripts. The best
>you can do now is learn how they do behave, and code accordingly.
>
In actual fact most of my scripts (anything over say 30 lines) are
usually do
Eric Blake wrote:
>> Anyhow I see that bash has taken the liberty of changing
>> the traditional acronym expansion from "Input Field Separator" to
>> "Internal Field Separator". A subtle difference.
>
> OK, you found a legitimate bug in the bash documentation. Perhaps Chet
> will change that fo
I have an animated gif that shows the bug. If you browse to:
http://bmi.osu.edu/~rutt/bashcompletion.gif
it will show how e.g.
cd $HOM
will expand to
cd \$HOME
I think this is a bug in the method:
_cd()
{
local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
[...]
}
My version is
27 matches
Mail list logo
