what is wrong here?

[Francky Leyn]

Hello,

consider the following code:

EXTENSION=jpg
INPUT_FILES=*.$EXTENSION

if [ -z "$INPUT_FILES" ]; then
  echo "No .$EXTENSION input files in this directory"
  exit -1
fi

Consider a dir with some .jpg files.
the if close is not executed.
This is correct.

Consider now a dir without .jpg files.
Then the if close also isn't executed, while it should.
The script isn't exited and runs further with all wrong
actions as consequence.

What is wrong here?

Best regards,

Francky Leyn

strange behavior of assignment

[Francky Leyn]

Hello,

consider the following snippet:

EXTENSION=png
INPUT_FILES=*.$EXTENSION

If there are for example 3 input files, an echo delivers:

echo $INPUT_FILES --> '01.png 02.png 03.png'

No we change the EXTENSION:

EXTENSION=jpg

Now, in a dir without jpg files the following happens:

INPUT_FILES=*.$EXTENSION
echo $INPUT_FILES  --> '*.jpg' instead of the empty string.

Is there any way I can optain an empty string?
I would like to test on the zeroness of INPUT_FILES.


Best regards,

Francky Leyn

Re: what is wrong here?

[mhenn]

Am 08.08.2011 11:33, schrieb Francky Leyn:
> Hello,
> 
> consider the following code:
> 
> EXTENSION=jpg
> INPUT_FILES=*.$EXTENSION

echo "$INPUT_FILES" #obviously wrong
#instead maybe
INPUT_FILES="$(ls *.$EXTENSION)"

> 
> if [ -z "$INPUT_FILES" ]; then
>   echo "No .$EXTENSION input files in this directory"
>   exit -1
> fi
> 
[...]
> 
> What is wrong here?
> 
> Best regards,
> 
> Francky Leyn

I think there are even better ways to do this, but this is one that came
to my mind at the moment.

btw:

man bash | less -p 'Pathname expansion'

Re: what is wrong here?

[mhenn]

Am 08.08.2011 14:17, schrieb mhenn:
> Am 08.08.2011 11:33, schrieb Francky Leyn:
>>[...]
> 
> echo "$INPUT_FILES" #obviously wrong
> #instead maybe
> INPUT_FILES="$(ls *.$EXTENSION)"
> 
>> [...]

That actually wasn't such a good advice:


Better use find or or a for loop like this:

for file in *.$EXTENSION; do
...
#but attention here: if no such a file exists,
# $file is "*.jpg" (with a literal asterisk)

#maybe break after the first found file?
done

Re: what is wrong here?

[Francky Leyn]

On 8/8/2011 2:17 PM, mhenn wrote:

Am 08.08.2011 11:33, schrieb Francky Leyn:

Hello,

consider the following code:

EXTENSION=jpg
INPUT_FILES=*.$EXTENSION


echo "$INPUT_FILES" #obviously wrong
#instead maybe
INPUT_FILES="$(ls *.$EXTENSION)"


I tried something similar:

INPUT_FILES=`ls *.$EXTENSION`

This worked when there were files.
But when there were no matching files, it didn't.
In that case the words of the ls error message were
considered as files, which is obviously wrong.

I'm new to bash, and have never seen a construct like yours.
Could you briefly explain what the dollar and the () mean (subshell)?

Btw: how can I get rid off the ls error message in your construct?
I tried already by postponing with >/dev/null, and 2>/dev/null, but
that all doesn't help. Is ls writting to /dev/tty? and in that case,
how can I suppress the ls error message?

Anyway, your construct works fine for files without spaces or newlines.
Now up to the link you have me.

Thanks for the help!


if [ -z "$INPUT_FILES" ]; then
   echo "No .$EXTENSION input files in this directory"
   exit -1
fi


[...]


What is wrong here?

Best regards,

Francky Leyn


I think there are even better ways to do this, but this is one that came
to my mind at the moment.

btw:

man bash | less -p 'Pathname expansion'

Re: what is wrong here?

[mhenn]

Am 08.08.2011 15:22, schrieb Francky Leyn:
> On 8/8/2011 2:17 PM, mhenn wrote:
>> Am 08.08.2011 11:33, schrieb Francky Leyn:
>>> Hello,
>>>
>>> consider the following code:
>>>
>>> EXTENSION=jpg
>>> INPUT_FILES=*.$EXTENSION
>>
>> echo "$INPUT_FILES" #obviously wrong
>> #instead maybe
>> INPUT_FILES="$(ls *.$EXTENSION)"
> 
> I tried something similar:
> 
> INPUT_FILES=`ls *.$EXTENSION`
> 
> This worked when there were files.
> But when there were no matching files, it didn't.
> In that case the words of the ls error message were
> considered as files, which is obviously wrong.
> 
> I'm new to bash, and have never seen a construct like yours.
> Could you briefly explain what the dollar and the () mean (subshell)?

`` also creates a subshell :)
and $() actually does the same. See
man bash | less -p '\$\(command'

> 
> Btw: how can I get rid off the ls error message in your construct?
> I tried already by postponing with >/dev/null, and 2>/dev/null, but
> that all doesn't help. Is ls writting to /dev/tty? and in that case,
> how can I suppress the ls error message?

INPUT_FILES="$(ls *.$EXTENSION 2>/dev/null)"
if [ -z "$INPUT_FILES" ]; then echo "no such file"; fi

> 
> Anyway, your construct works fine for files without spaces or newlines.
> Now up to the link you have me.
> 
> Thanks for the help!

np

sed problem

[Francky Leyn]

Hello,

I have the following problem: I must write a sed script that
converts parts of groff syntax to LaTeX syntax.

eg: .BI -o gif_output_file -> \textbf{-o} \textit{gif\_output\_file}

Lets neglect the underscores for the moment.

This can be dan with

s/\.BI \([^ ]*\) \([^ ]*\)/\\textbf{\1} \\textit{\2}/

However, it also has to work for:

eg: .BI -o " gif_output_file

It doesn't: this is the output:

\textbf{-o} \textit{"} gif\_output\_file"

Of couse.

My question: how do you write it correctly in sed?

Best reagrds,

Francky

Re: initialisation bash variables

[Patrick]

On 17.08.2011 20:53, Stephane CHAZELAS wrote:

2011-08-17, 08:32(+02), Francky Leyn:

On 8/16/2011 10:53 PM, Stephane CHAZELAS wrote:
2) If VAR coincides with an environment variable, and in the
 script I change it value, is this then propagated to outside
 the script? Is the environment variable affected?


The environment is a list of strings (by convention of the format
[...]

In no circumstance are variable definitions in one process going
to affect the environment of other processes (an exception to
that is the "fish" shell)



Could it be that the two of you are not talking about the same thing?

Just for clarity: environment variables (henceforth "the environment") 
of a process are (is) inherited by its children.


Therefore, what *does* happen, is that if Stephane, as in 2), changes 
VAR in script, the change gets propagated to the scripts *child* processes.


$ X=1 bash 1*)
 $ echo $X
 1
 $ X=2
 $ bash
  $ echo $X
  2

But what does of course not happen, is that the change would get 
propagated to the *parent* process.


$ export X=12*)
$ echo $X
1
 $ bash
 $ X=2
 $ exit
$ echo $X
1

1*) X will exist only in the environment of the child process being started
2*) X will exist in the environment of the current process and will 
therefore be inherited and exist in the environment of its children as well


(What is the "fish" shell ???)

I/O bug with big file?

[Erwan]

Hi all,

Here is a small test which shows what happens:

limit=5; x=1; while [ $x -le $limit ]; do printf "%010d\n" $x;
x=$(( $x + 1)); done >bigfile.txt
while read line; do echo -e "TEST\t$line"; done >bug.txt

Basically the first line creates a big 5Gb text file containing 500
millions numbered lines (no problem here). Then the second line reads
this file line by line and adds a prefix 'TEST' to each.
The problem is that after the line 0195225788, it goes wrong and loops
on the following sequence:

TEST 0195225788
TEST 225778
TEST 0195225779
TEST 0195225780
TEST 0195225781
TEST 0195225782
TEST 0195225783
TEST 0195225784
TEST 0195225785
TEST 0195225786
TEST 0195225787
TEST 0195225788
TEST 225778

(so don't forget to stop the script, the bug.txt file will grow
infinitely!)

tested on an Ubuntu 11.04:
uname -a
Linux bloom 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC
2011 i686 i686 i386 GNU/Linux
bash --version
GNU bash, version 4.2.8(1)-release (i686-pc-linux-gnu)

I posted this issue yesterday in the Ubuntu forums, the problem was
confirmed by another user:
http://ubuntuforums.org/showthread.php?t=1808384

Regards
Erwan

Behavior of calling return from a trap

[dave reisner]

Hi all,

I'm noticing some odd behavior in an ERR trap with errtrace. It's
present in bash 3.2 and as well as 4.2. The simplest reproduction is
as follows:

--8<--
#!/bin/bash

somefunc() {
  false
  echo "shouldn't see this"
}

set -E
trap -- 'return 1' ERR

somefunc
echo "should see this"
--8<--

Both versions of bash throw an error, though fwiw the line number
differs: bash4 blames the line of where the trap is fired versus bash3
which blames the line where the trap is declared. The entire output of
the script is:

foo: line 4: return: can only `return' from a function or sourced
script
should see this

So, both versions give the intended behavior of returning from the
function despite the error. imo, there's a bug here somewhere, I'm
just not sure if it's the faulty error being thrown or if I shouldn't
be expecting the trap to work as it is when it's declared outside of a
function.

Regards,
Dave

Re: Pathname expansion not performed in Here Documents

[Davide Baldini]

On 02/27/12 04:11, Dan Douglas wrote:

> "If word is unquoted, all lines of the here-document are subjected to 
> parameter expansion, command substitution, and arithmetic expansion."
> 
> No pathname expansion.

That section of manual doesn't specifically include word splitting nor
pathname expansion into the list of performed expansions, but the word
splitting does include itself unconditionally:

> Word Splitting
> The  shell  scans the results of parameter expansion, command substitu-
> tion, and arithmetic expansion that did not occur within double  quotes
> for word splitting.

and pathname expansion ties itself to word splitting:

> Pathname Expansion
> After  word  splitting, [...]

If intended behaviour is to exclude some expansions from performing word
splitting or pathname expansion, they should be specifically pointed out
in the manual, like the assignment operator section does:

> A variable may be assigned to by a statement of the form
> 
>   name=[value]
>  
> [...] All values undergo tilde expansion, parameter and variable
> expansion, command substitution, arithmetic expansion, and quote
> removal (see  EXPANSION below). [...] Word splitting is not
> performed, with the exception of "$@" as explained below under
> Special Parameters. Pathname expansion is not performed.

incompatibility in regex

[Peter Schreiber]

Hi,

have experienced the following:


3.1.17(1)-release:

-> [[ a =~ a|b ]] && echo true
-bash: syntax error in conditional expression: unexpected token `|'

-> [[ a =~ a\|b ]] && echo true   # that one works in version 3
true

===

4.1.10(4)-release:

-> [[ a =~ a\|b ]] && echo true   # ... but not in version 4

-> [[ a =~ a|b ]] && echo true
true


Do I really need to check BASH_VERSION first?

Thanks & regards,
Peter

Re: Edit vs delete a running script. Why difference?

[David Thomas]

On Jan 18, 5:22 am, Greg Wooledge  wrote:
> On Wed, Jan 18, 2012 at 01:19:20PM +0900, Teika Kazura wrote:
> > If the
> > entire script is read at invocation, then why should / does
> > modification affect? Is it a bug?
>
> The entire script *isn't* read at invocation.  Bash just reads a little
> bit at a time, as needed.

Interestingly, on many Linux systems this allows one to check
(crudely) how far a script has progressed by looking at /proc//
fdinfo/255.

Re: what is wrong here?

[Greg Wooledge]

On Mon, Aug 08, 2011 at 03:41:52PM +0200, mhenn wrote:
> Am 08.08.2011 15:22, schrieb Francky Leyn:
> > On 8/8/2011 2:17 PM, mhenn wrote:
> >> Am 08.08.2011 11:33, schrieb Francky Leyn:
> >>> consider the following code:
> >>>
> >>> EXTENSION=jpg
> >>> INPUT_FILES=*.$EXTENSION
> >>
> >> echo "$INPUT_FILES" #obviously wrong
> >> #instead maybe
> >> INPUT_FILES="$(ls *.$EXTENSION)"

They are both incorrect.  If you want a list of all the files that match
a glob, use an array to hold them:

files=(*.$extension)

Parameter expansion ($extension) happens before globbing (*.jpg), and
the results will be placed into an array.  Filenames with whitespace
will be handled correctly.

> > This worked when there were files.
> > But when there were no matching files, it didn't.

If you want the array to be empty when there are no matching files, then
you must enable bash's nullglob option:

shopt -s nullglob
files=(*.$extension)

See also http://mywiki.wooledge.org/BashFAQ/004 (checking/counting files)
 and http://mywiki.wooledge.org/BashFAQ/005 (arrays)
 and http://mywiki.wooledge.org/glob(globs)

Using ls in a script is almost always wrong, unless you're simply dumping
its output to a terminal for a human to read.  Use globs instead.

initialisation bash variables

[Francky Leyn]

Hello,

if you have a variable, say VAR,
and you don't assign it a value,
and afterwards you test it,
what is the value of $VAR then?

random, or an empty string?

Best regards,

Francky

Re: shopt can't set extglob in a sub-shell?

[Davide Baldini]

On 02/26/12 12:41, John Kearney wrote:
> I updated that wiki page
> Hopefully its clearer now.
> http://mywiki.wooledge.org/glob#extglob

Valuable information. I wonder if some of it should be included in the
user manual, at least to point out some possible misbehaviours one
wouldn't expect.

Re: Syntax Question...

[Patrick]

On 18.08.2011 12:44, Stephane CHAZELAS wrote:

2011-08-17, 08:24(-04), Greg Wooledge:

On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:

Ken Irving wrote:

Maybe this?
today_snaps=( ${snap_prefix} )



   but as you mention, that will put them into an arraysorry "imprecise
terminology" list for me is some number of objects in a string
separated by some
separator.


This is an extremely bad idea.  Legacy Bourne shell code from the
1980s kind of bad -- from the horrible days before we *had* arrays
in shells.  How are you going to handle filenames with spaces in them?
With newlines in them?  With commas in them?  With colons in them?  Tabs?
DEL characters?  Those are all valid in filenames.  Any delimiter you
can *put* in a shell string is also a valid character in a filename (or
at least in a pathname, which eliminates the possibility of using slash).



In this code:

today_snaps=( ${snap_prefix} )

With the default value of IFS in bash and without globbing
disabled, the problematic characters are SPC, TAB, NL, *, ?, [
and potentially more if you have extended globbing enabled.


I think this works! You're missing the context or something. 
"snap_prefix" is a shell glob pattern here, ending in *.


$ touch ' ' $'\t' $'\n' '*' '?' '['
$ snap_prefix=*  # no glob happening here!
$ today_snaps=( ${snap_prefix} ) # glob happening here and
 # the results are assigned to the
 # elements of the today_snaps array
$ for e in "${l[@]}"; do stat -c%N "$e"; done
`\t'
`\n'
` '
`*'
`?'
`['

I don't see a problem...

Writing to bash's tty too fast: workarounds?

[George]

I'm the maintainer of a terminal emulator on Mac OS and a user
reported that if he pastes a large string of the form:

cat << EOF > whatever.txt
blah blah blah
blah blah blah
... etc for 100k ...
EOF

That the output is badly mangled. I can reproduce this consistently
with a smallish test program. Having traced into readline, the culprit
seems to be that readline fiddles with the terminal between lines of
input (I'm pretty sure the things done in set_tty_settings() are
responsible, but I haven't proved it yet). This seems to cause it to
drop some or all of the input that's in the input buffer.

Is this a known issue? I can reproduce it on Linux as well, but it's
much less severe. The test case can be found here:

http://pastebin.com/as3KjEcq

To build on Mac, compile with
gcc bug.c -o bug -DMACOS

To build on Linux:
gcc bug.c /usr/lib/libutil.a -o bug

It should produce a file in your home directory called mytestfile.txt
that looks like this:
ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXY
ZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWX
YZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVW
etc.

On Linux, you get the occasional short line. On Mac OS, you get only a
few lines and they're very long.

I can reproduce this on Mac OS with the latest bash source build with
default settings.

Thanks for your help,
George

Re: incompatibility in regex

[Greg Wooledge]

On Mon, Oct 10, 2011 at 08:06:17PM +0200, Peter Schreiber wrote:
> 3.1.17(1)-release:
> 
> -> [[ a =~ a|b ]] && echo true
> -bash: syntax error in conditional expression: unexpected token `|'
> 
> -> [[ a =~ a\|b ]] && echo true   # that one works in version 3
> true
> 
> ===
> 
> 4.1.10(4)-release:
> 
> -> [[ a =~ a\|b ]] && echo true   # ... but not in version 4
> 
> -> [[ a =~ a|b ]] && echo true
> true
> 
> 
> Do I really need to check BASH_VERSION first?

Always store the regular expression that you intend to use on the
right hand side of =~ in a variable.

re='a|b'
if [[ $a =~ $re ]]; then ...

That is the only way to be sure it will work in whatever version of bash
you happen to be using.

print function in /examples/functions/kshenv

[Paul Tibbitts]

This is not a bug in bash itself, but I was wondering if there are any
updates to the ksh-compatibility print function provided with bash in
the source distribution (in the examples/functions/kshenv file),
specifically with regards to ksh-compatible handling of -R.

Using ksh:

$ print -R -z
-z

Using bash 4.2.10 with the kshenv file:

$ print -R -z
bash: illegal option -- z

My understanding is that the -R should disable further option
processing except for -n, and display any additional arguments,
including those beginning with "-"

I have worked around the problem to some extent by modifying the
function, but was wondering if anyone has a more accurate/efficient/
official/distributed version.

Thanks.

Paul

Re: {varname} for redirection does not work with arrays

[Bash M'head]

On Nov 5, 12:34 pm, Stephane CHAZELAS 
wrote:
> 2011-11-2, 12:01(-06), unkn...@vmw-les.eng.vmware.com:
> [...]> Description:
> >    If {varname} is an assoc. array in a redirection the exec will fail
> >    The [] should not be confused with pathname expansion just like ${}.
>
> > Repeat-By:
> >    $ declare -A array
> >    $ exec {array[key]}
> [...]
>
> In the documentation, it's {VARNAME} documented.
>
> zsh doesn't support {array[key]}
> ksh does though it's not documented (documented the same as
> bash).
>
> The work around is easy though:
>
> $ declare -A array
> $ exec {var} $ array[key]=$var
>
> --
> Stephane

Hello Stephane,
The workaround is trivial, its just inconsistent (with other parts
of bash).
I can say:

$ declare -A array
$ read -r 'array[key]' <<< 'foo'

This also makes arrays more directly useful.

$ declare -A fd
$ local fifo
$ exec {fifo}<"${fifo_path}"
$ fd[fifo]="${fifo}"
$ unset fifo

becomes

$ declare -A fd
$ exec {fd[fifo]}<"${fifo_path}"

Syntax coloring/highlighting in gnu-readline

[LanX]

Hi


>From my understanding of 
>http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html
it's OK to ask gnu-readline questions in this list.

I'm trying to interactively add colors while typing in readline and
using rl_event_hook to change rl_line_buffer seems to work.

Alas the ANSI escape codes for formatting which are allowed in the
prompt are not interpreted and shown as they are.


I learned from the old discussions I googled entering formatting code
would confuse cursor point and history entries.

Any other approach to achieve this?

Maybe a hook which does the final printing when a line is displayed,
where I could inject colors?

Cheers
  Rolf

Re: how to write this in bash

[mhenn]

Am 05.08.2011 17:47, schrieb Maverick:

> I also tried already
> 
> $CMD || echo 'Error...' && exit -1

see
man bash | less -p Compound

$CMD || { echo 'Error...'; exit -1; }

Re: excess braces ignored: bug or feature ?

[Davide Baldini]

On 02/17/12 20:51, Mike Frysinger wrote:
> FOO= BAR=bar
> : ${FOO:=${BAR}
> echo $FOO

Why should this be a bug? Your second line performs a parameter
expansion, all the remaining characters are joint into the token and
passed to ':'.
No bug.

Re: initialisation bash variables

[Francky Leyn]

On 8/15/2011 9:24 PM, Stephane CHAZELAS wrote:

2011-08-15, 17:15(+02), Francky Leyn:

Hello,

if you have a variable, say VAR,
and you don't assign it a value,
and afterwards you test it,
what is the value of $VAR then?

random, or an empty string?

[...]

Upon startup, the shell makes one shell variable per environment
variable whose name is compatible with shell variable names.

So for instance, if bash receives "VAR=foo" in its environemt,
$VAR will expand to foo. If it's passed "1=bar", $1 will not be
affected, and it's the same for a few special variables of the
shell.

If passed "A+B=C" or "=D" for instance, that obviously won't be
mapped to shell variables. Some shells do discard variables from
the environment that can't be mapped to shell variables. That's
not the case of bash.


If you don't initialise a sh/bash variable, and ask it up
afterwards, which value does it have then? Is that random
or the empty string?

At the moment I'm doing the following:

VAR=FALSE
# some command line procesing, that can set VAR to "TRUE"
if [ $VAR = TRUE ]; then
...
fi

Must I effectively write that VAR=FALSE?
Or will the script work fine without?

Also, can't I write the test as

if [ $VAR ]; then
...
fi

Regards,

Francky

Re: bash-4.2, crosscompiling and job control compile failure

[bigbigboy]

On Sep 15, 9:20 am, Chet Ramey  wrote:
> On 9/14/11 4:57 PM, Maciej Grela wrote:
>
> > In which tarball will your fix be released ? I don't understand the
> > code flow between the tarballs and git on savannah, the git repo
> > contains only imports from tarballs until 4.0, and the newest tarball
> > is 4.2.
>
> It will come out as part of bash-4.3.  It may be released as a patch to
> bash-4.2, but, based on the number of reports, it's not a high-priority
> issue.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    c...@case.edu    http://cnswww.cns.cwru.edu/~chet/

Chet,
I tried to cross compile with arm toolchain.
Would you please have a check if the following patch is proper?
Thanks!

diff --git a/execute_cmd.c b/execute_cmd.c
index 485b0c7..20be69a 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -2202,7 +2202,11 @@ execute_pipeline (command, asynchronous,
pipe_in, pipe_out, fds_to_close)
   /* If the `lastpipe' option is set with shopt, and job control is
not
  enabled, execute the last element of non-async pipelines in the
  current shell environment. */
+#if defined (JOB_CONTROL)
   if (lastpipe_opt && job_control == 0 && asynchronous == 0 &&
pipe_out == NO_PIPE && prev > 0)
+#else
+  if (lastpipe_opt && asynchronous == 0 && pipe_out == NO_PIPE &&
prev > 0)
+#endif
 {
   lstdin = move_to_high_fd (0, 0, 255);
   if (lstdin > 0)

Please... No Racing with the Planes

[Myra Perry]

'Philadelphia International Airport shut down temporarily Thursday
morning after a civilian drove onto the runway.'... More on story
here[http://tothecenter.com/2012/03/philadelphia-airport-shut-down-for-
car-on-the-runway/].

Re: String behaviour

[Michael Witten]

On Fri, Jun 24, 2011 at 10:38, BX  wrote:
> #/bin/bash
> # file1
> import()
> {
>   source file2
> }
>
> import
>
> echo v1=$v1, v2=$v2, v3=$v3
>
> #/bin/bash
> # file2
> v1=v1
> declare -x v2=v2
> declare v3=v3
>
> Run above script by
> $ bash file1
>
> Expected result: v1=v1, v2=v2, v3=v3
> Real result: v1=v1, v2=, v3=

>From the documentation here:

  info '(bash)Shell Functions'

we have:

  When the name of a shell function is used as a
  simple command name, the list of commands
  associated with that function name is executed.
  Shell functions are executed in the current shell
  context; no new process is created to interpret
  them.

  ...

  The BODY of the function is the compound
  command COMPOUND-COMMAND

and from:

  info '(bash)Command Grouping'

we have:

  Placing a list of commands between curly braces
  causes the list to be executed in the current
  shell context.  No subshell is created.

and from:

  info '(bash)Bourne Shell Builtins'

we know that the `source' builtin works as follows:

  Read and execute commands from the FILENAME
  argument in the current shell context

and from:

  info '(bash)Bash Builtins'

we have

  When used in a function, `declare' makes each
  NAME local, as with the `local' command, unless
  the `-g' option is used.

So, basically, the results are as expected: You execute the function
`import', which executes `source file2' in the current shell context,
which creates the variable `v1' in the current shell context, but
creates the variables `v2' and `v3' local to the function being
executed in the current shell context, so that by the echo statement,
only `v1' is defined.

Sincerely,
Michael Witten

Re: bash-4.2, crosscompiling and job control compile failure

[Chet Ramey]

On 9/16/11 12:35 PM, bigbigboy wrote:
> On Sep 15, 9:20 am, Chet Ramey  wrote:
>> On 9/14/11 4:57 PM, Maciej Grela wrote:
>>
>>> In which tarball will your fix be released ? I don't understand the
>>> code flow between the tarballs and git on savannah, the git repo
>>> contains only imports from tarballs until 4.0, and the newest tarball
>>> is 4.2.
>>
>> It will come out as part of bash-4.3.  It may be released as a patch to
>> bash-4.2, but, based on the number of reports, it's not a high-priority
>> issue.

This came out as bash-4.2 patch 18.

-- 
``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: print function in /examples/functions/kshenv

[Chet Ramey]

On 8/20/11 11:17 PM, Paul Tibbitts wrote:
> This is not a bug in bash itself, but I was wondering if there are any
> updates to the ksh-compatibility print function provided with bash in
> the source distribution (in the examples/functions/kshenv file),
> specifically with regards to ksh-compatible handling of -R.
> 
> Using ksh:
> 
> $ print -R -z
> -z
> 
> Using bash 4.2.10 with the kshenv file:
> 
> $ print -R -z
> bash: illegal option -- z
> 
> My understanding is that the -R should disable further option
> processing except for -n, and display any additional arguments,
> including those beginning with "-"
> 
> I have worked around the problem to some extent by modifying the
> function, but was wondering if anyone has a more accurate/efficient/
> official/distributed version.

If you have improvements to the function, please send them to me and I will
incorporate them into the bash distribution.  There's nothing official
about those functions; they're just examples.


-- 
``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: Bug fix for $((x**y)) algorithm on 64+ bits machines.

[Chet Ramey]

On 9/19/11 2:35 PM, Stephane CHAZELAS wrote:

> FYI, ksh93 uses pow(3). So does zsh, but only in floating point
> mode.
> 
> Probably better and more efficient than reinventing the wheel.

Maybe, but since bash doesn't use floating point arithmetic, probably
not.


-- 
``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: COMP_POINT is not set correctly when there is non-ascii characters in the command line.

[Chet Ramey]

On 3/27/12 2:17 PM, Yichao Yu wrote:
> So is it possible to set COMP_POINT as the number of characters
> between 0 and rl_point (if it is also bad to break libreadline api by
> setting rl_point as that.) without screwing up other part of the code?
> (I hope this fix would be no more than searching for rl_point and
> replace wherever necessary.)

I was going to respond that to break the relationship between COMP_POINT
and rl_point makes it very difficult, if not impossible, to identify the
character under the cursor when completion is attempted, but I'm not
sure how much that actually matters.  You can't assign rl_point using
this, so that's not an issue either.

Pretty much everything else in bash uses characters, which may be bytes
depending on the locale.

Can someone who's more familiar with the bash completion package tell me
whether or not it uses COMP_POINT at all?  That's about that only thing
I can think of that would use it.

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: COMP_POINT is not set correctly when there is non-ascii characters in the command line.

[Yichao Yu]

On Wed, Mar 28, 2012 at 10:48 PM, Chet Ramey  wrote:
> On 3/27/12 2:17 PM, Yichao Yu wrote:
>> So is it possible to set COMP_POINT as the number of characters
>> between 0 and rl_point (if it is also bad to break libreadline api by
>> setting rl_point as that.) without screwing up other part of the code?
>> (I hope this fix would be no more than searching for rl_point and
>> replace wherever necessary.)
>
> I was going to respond that to break the relationship between COMP_POINT
> and rl_point makes it very difficult, if not impossible, to identify the
> character under the cursor when completion is attempted, but I'm not
> sure how much that actually matters.  You can't assign rl_point using
> this, so that's not an issue either.

Sorry didn't get it. Bash can always internally access rl_point (to
"identify the character under the cursor") whether or not it is the
same with COMP_POINT and the script CANNOT "identify the character
under the cursor" using current value of COMP_POINT since
${COMPLINE:blah:blah} substitution count character instead of byte.
And this really matters, see the bash-completion bug report I link
below.
(Agree that rl_point should be kept the locale independent byte
counting value as what it is now.)

>
> Pretty much everything else in bash uses characters, which may be bytes
> depending on the locale.
>
> Can someone who's more familiar with the bash completion package tell me
> whether or not it uses COMP_POINT at all?  That's about that only thing
> I can think of that would use it.

It DOES use COMP_POINT. And this is the most annoy thing and also how
I notice the issue. I reported a bug for bash-completion here
(https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=313583&group_id=100114)
and soon discovered this is a bush issue.

Yichao Yu

>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    c...@case.edu    http://cnswww.cns.cwru.edu/~chet/