Re: Consume only up to 8 bit octal input for backslash-escaped chars (echo, printf)

[Roman Rakus]

On 12/08/2010 02:19 AM, Chet Ramey wrote:

On 12/7/10 11:12 AM, Roman Rakus wrote:

This one is already reported on coreutils:
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574

The problem is with numbers higher than /0377; echo and printf consumes all
3 numbers, but it is not 8-bit number. For example:
$ echo -e '\0610'; printf '\610 %b\n' '\610 \0610'
Should output:
10
10 10 10
instead of
�
� � �

No, it shouldn't.  This is a terrible idea.  All other shells I tested
behave as bash does*, bash behaves as Posix specifies, and the bash
behavior is how C character constants work.  Why would I change this?

Just wanted to work as coreutils. But ok, you can choose ;)

(*That is, consume up to three octal digits and mask off all but the lower
8 bits of the result.)

Yep. Nothing against this.

Chet


RR

Re: Consume only up to 8 bit octal input for backslash-escaped chars (echo, printf)

[Don Cragun]

On Dec 7, 2010, at 6:02 PM, Eric Blake wrote:
> [adding the Austin Group]
> 
> On 12/07/2010 06:19 PM, Chet Ramey wrote:
>> On 12/7/10 11:12 AM, Roman Rakus wrote:
>>> This one is already reported on coreutils:
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?msg=2;bug=7574
>>> 
>>> The problem is with numbers higher than /0377; echo and printf consumes all
>>> 3 numbers, but it is not 8-bit number. For example:
>>> $ echo -e '\0610'; printf '\610 %b\n' '\610 \0610'
>>> Should output:
>>> 10
>>> 10 10 10
>>> instead of
>>> �
>>> � � �
>> 
>> No, it shouldn't.  This is a terrible idea.  All other shells I tested
>> behave as bash does*, bash behaves as Posix specifies, and the bash
>> behavior is how C character constants work.  Why would I change this?
>> 
>> (*That is, consume up to three octal digits and mask off all but the lower
>> 8 bits of the result.)
> 
> POSIX states for echo:

Note that the behavior of echo is implementation-defined if a
 character appears on any of echo's operands unless the
X/Open System Interfaces option is supported by the implementation.

> 
> "\0num Write an 8-bit value that is the zero, one, two, or three-digit
> octal number num."
> 
> It does not explicitly say what happens if a three-digit octal number is
> not an 8-bit value, so it is debatable whether the standard requires at
> most an 8-bit value (two characters, \0061 followed by 0) or whether the
> overflow is silently ignored (treated as one character \0210), or some
> other treatment.

If the XSI option is supported, the behavior of \0xxx is implicitly
unspecified if xxx is 400(octal) or larger.  If you believe this is
not enough, we could change the text to make this situation explicitly
unspecified by changing:
If more than two hexadecimal digits immediately follow \x,
the results are unspecified.
in the current resolution of bug ID 249 to:
If more than two hexadecimal digits immediately follow \x
or if the octal value specified by /XXX will not fit in a
byte, the results are unspecified.

> 
> The C99 standard states (at least in 6.4.4.4 of the draft N1256 document):
> 
> "The value of an integer character constant containing more than one
> character (e.g., 'ab'), or containing a character or escape sequence
> that does not map to a single-byte execution character, is
> implementation-defined."

The specification of \0xxx in echo with the XSI option is intended to
behave as UNIX System V behaved as specified by the System V Interface
Definition, version 3 (SVID3).  (SVID3 was one of the base documents of
the original POSIX.2 standard, but since BSD systems and UNIX System V
systems had different behavior for echo, the original POSIX.2 standard
left the behavior unspecified (allowing the then current implementations
to continue to behave as they had).  The X/Open Portability Guide, Issue 3
continued to require the behavior as specified in SVID3.  When the original
POSIX.2 and XPG3 were merged in a later revision of the standards, we got
the XSI option (which required the System V behavior); but when XSI option
support is not claimed the old BSD or System V behavior is allowed.

 - Don

> 
> leaving '\610' as an implementation-defined character constant.
> 
> The Java language specifically requires "\610" to parse as "\061"
> followed by "0", and this can be a very useful property to rely on in
> this day and age where 8-bit bytes are prevalent.
> 
> http://austingroupbugs.net/view.php?id=249 is standardizing $'' in the
> shell, and also states:
> 
> "\XXX yields the byte whose value is the octal value XXX (one to three
> octal digits)"
> 
> and while it is explicit that $'\xabc' is undefined (as to whether it
> maps to $'\xab'c or to $'\u0abc' or to something else), it does not have
> any language talking about what happens when an octal escape does not
> fit in a byte.
> 
> Personally, I would love it if octal escapes were required to stop
> parsing after two digits if the first digit is > 3, but given that C99
> leaves it implementation defined, I think we need a POSIX interpretation
> to resolve the issue.  Also, I think this report means that we need to
> tweak the wording of bug 249 (adding $'') to deal with the case of an
> octal escape where three octal digits do not fit in 8 bits (either by
> explicitly declaring it unspecified, as is the case with \x escapes; or
> by requiring implementation-defined behavior, as in C99; or by requiring
> explicit end-of-escape after two digits, as in Java).
> 
> -- 
> Eric Blake   ebl...@redhat.com+1-801-349-2682
> Libvirt virtualization library http://libvirt.org

Recursively calling a bash script goes undetected and eats all system memory

[Diggory Hardy]

Hello,

With a simple script such as that below, bash can enter an infinite loop of 
eating memory until the system is rendered unusable:

#!/bin/bash
PATH=~
infinitely-recurse

Save this as infinitely-recurse in your home directory and run - and make sure 
you kill it pretty quick. OK, so an obvious bug when put like this, though it 
bit me recently (mistakenly using PATH as an ordinary variable and having a 
script with the same name as a system program). Would it not be simple to add 
some kind of protection against this — say don't let a script call itself more 
than 100 times?

Thanks,
Diggory

bash crashes with named pipes

[Kevin]

Maybe I'm doing something wrong, but the following will make bash
crash.


terminal 2:
$ mkfifo test
$ while true; do echo foo && sleep 1; done > test

terminal 1:
$ 

Re: Indirect expansion and arrays

[Mart Frauenlob]

On 29.07.2010 22:55, Bernd Eggink wrote:

It seems that indirect expansion doesn't work with arrays:

$ a=(x y z)
$ b=a
$ echo "${!b[0]} ${!b[1]} ${!b[2]}"
x

Is that intended? The documentation isn't explicit about it.

IMHO it would be very desirable to have a indirect expansion facility
for arrays. Otherwise there is only a choice between passing all
elements to a function, which is time-consuming, or using eval, which is
cumbersome and error-prone.




yes, that would be nice - as a feature.
but it somehow conflicts logically with ${!arr...@]}, which returns the 
indicies of an array (some ksh derivied feature I think).

cd with multiple arguments?

[Keith Thompson]

I'm not sure whether this is a bug (the documentation doesn't address
this case), but it's at least mildly annoying.

If you invoke the "cd" commands with extra arguments after the directory
name, all the extra arguments are silently ignored.

I noticed this when I accidentally typed a '/' when I meant to type ';'
in a long command:

( cd /some/dir / execute some command )

rather than the intended:

( cd /some/dir ; execute some command )

and didn't get an error or warning message -- and of course the command
wasn't executed.

$ echo $BASH_VERSION
3.2.48(1)-release
$ uname -a
Linux kvetch 2.6.28-19-generic #64-Ubuntu SMP Wed Aug 18 20:55:57 UTC
2010 i686 GNU/Linux
$ cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"
$ cd /tmp and all following arguments are silently ignored
$ pwd
/tmp
$ dirs
/tmp
$ 

3.2.48 is the version installed by Ubuntu.  I see the same issue with
bash version 4.1.0(1)-release (compiled from source on the same system).

(For what it's worth, tcsh and ksh both give error messages.)

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: cd with multiple arguments?

[Keith Thompson]

Keith Thompson  writes:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
>
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments are silently ignored.
[description snipped]

"pushd", "popd", and "pwd" also silently ignore extra arguments.
("dirs" doesn't; it prints an error message.)

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: "gitk &" closes parent bash upon exit

[Keith Thompson]

"Illia Bobyr"  writes:
[...]
>  When I do "gitk &" upon gitk exit the parent bash process 
> terminates as well.
>  When I do "(gitk &)" it works fine.  There does not seem to be any 
> crash dumps.  But sometimes bash outputs "Logout" before it exits just 
> as if I would press ^D on prompt.  I have tried putting "gitk &" call 
> into a script and adding traps for all possible signals but none seemed 
> to be fired.
>  You do not have to be in a directory that is a Git repository.

I wonder how "set -o ignoreeof" in the parent shell would affect
the behavior.

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: "gitk &" closes parent bash upon exit

[Keith Thompson]

Keith Thompson  writes:
> "Illia Bobyr"  writes:
> [...]
>>  When I do "gitk &" upon gitk exit the parent bash process 
>> terminates as well.
>>  When I do "(gitk &)" it works fine.  There does not seem to be any 
>> crash dumps.  But sometimes bash outputs "Logout" before it exits just 
>> as if I would press ^D on prompt.  I have tried putting "gitk &" call 
>> into a script and adding traps for all possible signals but none seemed 
>> to be fired.
>>  You do not have to be in a directory that is a Git repository.
>
> I wonder how "set -o ignoreeof" in the parent shell would affect
> the behavior.

I don't see this behavior, either with or without "set -o ignoreeof".

I see a pop-up error message: "Cannot find a git repository here";
when I click "OK" the message vanishes, gitk terminates, and the
parent bash shell is undisturbed.  Same thing whether bash is
running under rxvt, xterm, or a Windows command window.

$ cygcheck -c -d cygwin gitk bash
Cygwin Package Information
Package  Version
bash 3.2.49-23
cygwin   1.7.5-1
gitk 1.7.0.4-2

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

comparison inside [[]] is not numeric comparison?

[john.ruckstuhl]

In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
This isn't what I expected.
Which part of the documentation would set me straight?  If someone
could quote the fine manual, that would be great.

$ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
pass

$ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
wierd

$ set | grep BASH_VERSION
BASH_VERSION='3.2.51(24)-release'

Thanks,
John R.

Re: comparison inside [[]] is not numeric comparison?

[Greg Wooledge]

On Fri, Nov 19, 2010 at 04:45:15PM -0800, john.ruckstuhl wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?

Correct.  Assuming you use the string-comparison operators (> and <)
rather than the integer-comparison operators (-gt, -lt, etc.).

> $ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
> wierd

String comparison.  If you want to do numeric comparisons, use ((...))
or use -gt.

if ((1000 > 200)); then echo pass; else echo weird; fi
if [[ 1000 -gt 200 ]]; then echho pass; else echo weird; fi

Re: comparison inside [[]] is not numeric comparison?

[Dennis Williamson]

On Fri, Nov 19, 2010 at 6:45 PM, john.ruckstuhl
 wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight?  If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
> pass
>
> $ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
> wierd
>
> $ set | grep BASH_VERSION
> BASH_VERSION='3.2.51(24)-release'
>
> Thanks,
> John R.
>

In man bash, in the CONDITIONAL EXPRESSIONS section:

string1 < string2
  True  if  string1  sorts before string2 lexicographically in the
  current locale.

Re: Recursively calling a bash script goes undetected and eats all system memory

[Bob Proulx]

Diggory Hardy wrote:
> With a simple script such as that below, bash can enter an infinite
> loop of eating memory until the system is rendered unusable:
> 
> #!/bin/bash
> PATH=~
> infinitely-recurse

Yes, of course.  It calls itself repeatedly and every copy consumes
just a little more system resources until they are all consumed.

> Save this as infinitely-recurse in your home directory and run - and
> make sure you kill it pretty quick.

This is a simpler variation on the classic fork bomb.

  http://en.wikipedia.org/wiki/Fork_bomb

> OK, so an obvious bug when put like this, though it bit me recently
> (mistakenly using PATH as an ordinary variable and having a script

Have you ever cut yourself on a kitchen knife?  I am sure the answer
is yes because we all have at one time or another.  As a thought
experiment design a kitchen knife in which it would be impossible to
cut yourself.  Take some time to think about it.  You could install
some type of safety guard.  You could use some type of box.  Perhaps
some pull cords to keep hands back in some way.

Now is the important question.  After having designed the safe kitchen
knife that wil prevent you from ever cutting yourself would you
actually use such a knife yourself?

> with the same name as a system program). Would it not be simple to
> add some kind of protection against this — say don't let a script
> call itself more than 100 times?

Detecting and avoiding this is actually not a simple thing to do at
all.  This is really a much harder problem than you think it is and
isn't something that can be fixed in bash.  The best result is simply
learning to avoid the problem.

Bob

Re: comparison inside [[]] is not numeric comparison?

[Dennis Williamson]

On Thu, Dec 9, 2010 at 10:48 AM, Dennis Williamson
 wrote:
> On Fri, Nov 19, 2010 at 6:45 PM, john.ruckstuhl
>  wrote:
>> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
>> This isn't what I expected.
>> Which part of the documentation would set me straight?  If someone
>> could quote the fine manual, that would be great.
>>
>> $ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
>> pass
>>
>> $ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
>> wierd
>>
>> $ set | grep BASH_VERSION
>> BASH_VERSION='3.2.51(24)-release'
>>
>> Thanks,
>> John R.
>>
>
> In man bash, in the CONDITIONAL EXPRESSIONS section:
>
> string1 < string2
>              True  if  string1  sorts before string2 lexicographically in the
>              current locale.
>

I meant to include:

Use (( ... ))

$ if (( 1000 > 200 )); then echo pass; else echo wierd; fi
pass

Re: comparison inside [[]] is not numeric comparison?

[Daniel Fleischman]

>From "man bash"

When  used with [[, The < and > operators sort lexicographically
  using the current locale.

You want (( and )):

$ if (( 1000 > 200 )); then echo pass; else echo wierd; fi
pass

Daniel.

On Fri, Nov 19, 2010 at 19:45, john.ruckstuhl wrote:

> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight?  If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
> pass
>
> $ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
> wierd
>
> $ set | grep BASH_VERSION
> BASH_VERSION='3.2.51(24)-release'
>
> Thanks,
> John R.
>

Re: cd with multiple arguments?

[Eric Blake]

On 09/23/2010 10:47 AM, Keith Thompson wrote:
> I'm not sure whether this is a bug (the documentation doesn't address
> this case), but it's at least mildly annoying.
> 
> If you invoke the "cd" commands with extra arguments after the directory
> name, all the extra arguments are silently ignored.

I would really love it if bash copied the zsh behavior here:

cd a b

tries to find a directory matching the extglob

a+([$' \t'])b

and fails if there are multiple matches or no matches.  Certainly less
typing than remembering to quote the argument, via cd 'a b'.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: comparison inside [[]] is not numeric comparison?

[Pierre Gaston]

On Sat, Nov 20, 2010 at 2:45 AM, john.ruckstuhl
 wrote:
> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?
> This isn't what I expected.
> Which part of the documentation would set me straight?  If someone
> could quote the fine manual, that would be great.
>
> $ if [[ 2000 > 200 ]]; then echo pass; else echo wierd; fi
> pass
>
> $ if [[ 1000 > 200 ]]; then echo pass; else echo wierd; fi
> wierd
>
> $ set | grep BASH_VERSION
> BASH_VERSION='3.2.51(24)-release'
>
> Thanks,
> John R.
>,

http://www.gnu.org/software/bash/manual/bash.html#Bash-Conditional-Expressions

string1 < string2
True if string1 sorts before string2 lexicographically.
string1 > string2
True if string1 sorts after string2 lexicographically.

Re: comparison inside [[]] is not numeric comparison?

[Andreas Schwab]

"john.ruckstuhl"  writes:

> In bash, a comparison inside "[["/"]]" is lexicographic not numeric?

[[ ... ]] uses the same operators as test, so if you want numeric
comparison you need to use -gt, -lt, etc.

> Which part of the documentation would set me straight?

$ help [[

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Redirection and old version of bash

[Gerard Seibert]

I have a script that I wrote and use successfully on FreeBSD with bash
version 4.1.9(0)-release (amd64-portbld-freebsd8.1). The script uses a
redirection "2>/dev/null" in several places. For some reason, that
does not seem to be working correctly under an old version of bash;
i.e. GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9).

Specifically, this was occurring with rsync displaying messages of the
day, etc. This only happens under this version of Bash and apparently
only under Solaris.

I have managed to circumvent the problem; however, I was just
interested in knowing if anyone had heard of this before.

-- 
Gerard ✌
ger...@seibercom.net

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
Old MacDonald had an agricultural real estate tax abatement.

Re: Recursively calling a bash script goes undetected and eats all system memory

[Pierre Gaston]

On Wed, Dec 8, 2010 at 11:15 AM, Diggory Hardy  wrote:
> Hello,
>
> With a simple script such as that below, bash can enter an infinite loop of 
> eating memory until the system is rendered unusable:
>
> #!/bin/bash
> PATH=~
> infinitely-recurse
>
> Save this as infinitely-recurse in your home directory and run - and make 
> sure you kill it pretty quick. OK, so an obvious bug when put like this, 
> though it bit me recently (mistakenly using PATH as an ordinary variable and 
> having a script with the same name as a system program). Would it not be 
> simple to add some kind of protection against this — say don't let a script 
> call itself more than 100 times?
>
> Thanks,
> Diggory
>
Well, I'm not a big fan of the technique, but out there I see a lot of
wrapper scripts calling themselves to automatically restart an
application.

Encoding oddity

[Richard]

Hi!

OS X 10.6.x

I am trying to loop over some files with extended characters.
Everything works fine if I hardcode the path, see example 1,
but if I use a for loop with a * wildcard, I get some problems,
see example 2.

The problems seems to be that the extended character -- é -- in the
hardcoded path, gets translated to the html equivalent of é,
whereas the for loop with the wildcard, variable $b in the second example,
translates the -- é -- to the html equivalent of ́.

Due to this, [[ $b == $myfile ]] is never true in the second example, even 
though
it would be expected based on what I actually check for.

Does anyone have any solution to this problem?

Thanks!


--
#!/bin/bash

touch /Users/myuser/pretérito.txt

# Example 1
myfile="/Users/myuser/pretérito.txt"

for b in "$myfile"; do
if [[ $b == $myfile ]]; then
echo "OK 1: $b -- $myfile"
fi
done

# Example 2
myfolder="/Users/myuser/"
unset b
for b in "$myfolder"*; do
if [[ $b == $myfile ]]; then
echo "OK 2: $b -- $myfile"
fi
done
-

Richard Taubo

Encoding oddity

[Richard]

Hi!

OS X 10.6.x

I am trying to loop over some files with extended characters.
Everything works fine if I hardcode the path, see example 1,
but if I use a for loop with a * wildcard, I get some problems,
see example 2.

The problems seems to be that the extended character -- é -- in the
hardcoded path, gets translated to the html equivalent of é,
whereas the for loop with the wildcard, variable $b in the second example,
translates the -- é -- to the html equivalent of ́.

Due to this, [[ $b == $myfile ]] is never true in the second example, even 
though
it would be expected based on what I actually check for.

Does anyone have any solution to this problem?

Thanks!


--
#!/bin/bash

touch /Users/myuser/pretérito.txt

# Example 1
myfile="/Users/myuser/pretérito.txt"

for b in "$myfile"; do
if [[ $b == $myfile ]]; then
echo "OK 1: $b -- $myfile"
fi
done

# Example 2
myfolder="/Users/myuser/"
unset b
for b in "$myfolder"*; do
if [[ $b == $myfile ]]; then
echo "OK 2: $b -- $myfile"
fi
done
-

Richard Taubo

Re: cd with multiple arguments?

[Chet Ramey]

On 12/9/10 11:30 AM, Eric Blake wrote:
> On 09/23/2010 10:47 AM, Keith Thompson wrote:
>> I'm not sure whether this is a bug (the documentation doesn't address
>> this case), but it's at least mildly annoying.
>>
>> If you invoke the "cd" commands with extra arguments after the directory
>> name, all the extra arguments are silently ignored.
> 
> I would really love it if bash copied the zsh behavior here:
> 
> cd a b
> 
> tries to find a directory matching the extglob
> 
> a+([$' \t'])b
> 
> and fails if there are multiple matches or no matches.  Certainly less
> typing than remembering to quote the argument, via cd 'a b'.

It's trivial to write a shell function to do that, and many other things.

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: Encoding oddity

[Dennis Williamson]

On Thu, Dec 9, 2010 at 7:11 PM, Richard  wrote:
> Hi!
>
> OS X 10.6.x
>
> I am trying to loop over some files with extended characters.
> Everything works fine if I hardcode the path, see example 1,
> but if I use a for loop with a * wildcard, I get some problems,
> see example 2.
>
> The problems seems to be that the extended character -- é -- in the
> hardcoded path, gets translated to the html equivalent of é,
> whereas the for loop with the wildcard, variable $b in the second example,
> translates the -- é -- to the html equivalent of ́.
>
> Due to this, [[ $b == $myfile ]] is never true in the second example, even 
> though
> it would be expected based on what I actually check for.
>
> Does anyone have any solution to this problem?
>
> Thanks!
>
>
> --
> #!/bin/bash
>
> touch /Users/myuser/pretérito.txt
>
> # Example 1
> myfile="/Users/myuser/pretérito.txt"
>
> for b in "$myfile"; do
>        if [[ $b == $myfile ]]; then
>                echo "OK 1: $b -- $myfile"
>        fi
> done
>
> # Example 2
> myfolder="/Users/myuser/"
> unset b
> for b in "$myfolder"*; do
>        if [[ $b == $myfile ]]; then
>                echo "OK 2: $b -- $myfile"
>        fi
> done
> -
>
> Richard Taubo
>

        if [[ $b == $myfolder$myfile ]]; then

Try

echo $myfolder/*

you will see that each file has the directory name prepended.