Re: Directory completion problems
To be exact, symlink is in the directory ~/a, and it points to ~/test and there is also a directory ~/.java. So, after cd ~/a/symlink, there are two ../.java files -- one in the physical parent, and one in the logical parent. The former is a directory, the latter is a plain file. ~/a/symlink$ cd ../ produces one alternative: .java, but only if the plain file .java exists. So, it seems that filenames of all ~/ directories seem to be matched against filenames of all ~/a/ files of any kind, and the AND result is used by the completion. But, if there is some directory in the logical directory, that does not have its namesake in the physical directory, it is ignored: ls -la ~/a total 16 drwxr-xr-x 4 art art 4096 Apr 23 09:51 . drwxr-xr-x 83 art art 4096 Apr 23 09:51 .. drwxr-xr-x 2 art art 4096 Apr 19 14:48 .hidden drwxr-xr-x 2 art art 4096 Apr 23 09:51 i -rw-r--r-- 1 art art0 Apr 23 09:40 .java lrwxrwxrwx 1 art art7 Apr 19 14:48 symlink -> ../test ~/a/symlink$ cd ../i [completion shows only .java, but cd works for i as well] ~/a/i$ To sum that up, files in the logical directory sometimes affect the cd completion even that they are not directories at all, and sometimes they are ignored even that they are directories indeed.
Re: Passing variables by reference conflicts with local
On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
> It appears that `unset' is capable of traversing down the call-stack and
> unsetting variables repeatedly:
>
>a=0 b=0 c=0 d=0 e=0
>_unset() { unset -v b c c d d d e; }
>t1() {
>local a=1 b=1 c=1 d=1
>t2
>}
>t2() {
>local a=2 b=2 c=2 d=2 e=2
>_unset
>echo a:$a b:$b c:$c d:$d e:$e
>}
>t1 # Outputs: a:2 b:1 c:0 d: e:0
>#^ ^ ^ ^ ^-- unset once (skipped t1)
>#| | | +- unset thrice to global
>#| | +- unset twice till global
>#| +- unset once till t1
>#+- unset not
>
> It seems to work on bash-3.0, 3.2, 4.0 and 4.1.
> Is this a bug or a feature?
>
When I revisit this 2 years old thread I don't understand why following
foo() function does not output the global var:
$ cat foo.sh
var=global
foo()
{
local var=foo
unset var
echo foo: $var
}
bar_unset()
{
unset var
}
bar()
{
local var=bar
bar_unset
echo bar: $var
}
foo
bar
$ bash foo.sh
foo:
bar: global
$
In foo() it unsets its local var so why doesn't the subsequent $var refer
to the global var?
>
> Freddy Vulto
> http://fvue.nl/wiki/Bash:_passing_variables_by_reference
>
>
>
Internal 'echo' command doesn't handle I/O errors on close file
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-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
uname output: Linux dhcp-10-30-20-255.sw.ru 2.6.32-042stab054.1 #1 SMP Fri
Mar 30 01:41:10 MSD 2012 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.1
Patch Level: 2
Release Status: release
Description:
Internal 'echo' command doesn't handle I/O errors on close file when I try
redirect
standart output to mounted filesystem without free space.
Try redirect stdout of echo command to mounted filesystem without free space
[user@host ~]# echo "bla-bla-bla" > /mnt/fs/out.txt
[user@host ~]# echo $?
0
i.e. it means that all ok, but operation was failed.
Try the same action for /bin/echo
[user@host ~]# /bin/echo "bla-bla-bla" > /mnt/fs/out.txt
/bin/echo: write error: No space left on device
[user@host ~]# echo $?
1
valid behaviour
Strace show that errors from /bin/bash were ignored:
[user@host ~]# strace echo "bla-bla-bla" > /mnt/fs/out.txt
execve("/bin/echo", ["echo", "bla-bla-bla"], [/* 22 vars */]) = 0
brk(0) = 0x2467000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d362000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=36827, ...}) = 0
mmap(NULL, 36827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f766d359000
close(3)= 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355!b2\0\0\0"..., 832)
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1979000, ...}) = 0
mmap(0x326220, 3803304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x326220
mprotect(0x3262397000, 2097152, PROT_NONE) = 0
mmap(0x3262597000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x3262597000
mmap(0x326259c000, 18600, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x326259c000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d358000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d357000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d356000
arch_prctl(ARCH_SET_FS, 0x7f766d357700) = 0
mprotect(0x3262597000, 16384, PROT_READ) = 0
mprotect(0x326201f000, 4096, PROT_READ) = 0
munmap(0x7f766d359000, 36827) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99158704, ...}) = 0
mmap(NULL, 99158704, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f76674c5000
close(3)= 0
brk(0) = 0x2467000
brk(0x2488000) = 0x2488000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2512, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d361000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2512
read(3, "", 4096) = 0
close(3)= 0
munmap(0x7f766d361000, 4096)= 0
open("/usr/lib/locale/posix/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No
such file or directory)
fstat(1, {st_mode=S_IFREG|0700, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f766d361000
write(1, "bla-bla-bla\n", 12) = 12
close(1)= -1 ENOSPC (No space left on
device)
munmap(0x7f766d361000, 4096)= 0
write(2, "echo: ", 6echo: ) = 6
write(2, "write error", 11write error) = 11
write(2, ": No space left on device", 25: No space left on device) = 25
write(2, "\n", 1
) = 1
exit_group(1) = ?
Re: Internal 'echo' command doesn't handle I/O errors on close file
On Mon, Apr 23, 2012 at 02:38:47PM +0400, Andrey Zaitsev wrote:
> Strace show that errors from /bin/bash were ignored:
>
> [user@host ~]# strace echo "bla-bla-bla" > /mnt/fs/out.txt
> execve("/bin/echo", ["echo", "bla-bla-bla"], [/* 22 vars */]) = 0
If you want an strace of the internal echo, you have to do it this
way:
# strace bash -c 'echo "bla-bla-bla" > /mnt/fs/out.txt'
In fact it's the redirection whose failure you really care about.
Re: Internal 'echo' command doesn't handle I/O errors on close file
Greg Wooledge writes:
> On Mon, Apr 23, 2012 at 02:38:47PM +0400, Andrey Zaitsev wrote:
>> Strace show that errors from /bin/bash were ignored:
>>
>> [user@host ~]# strace echo "bla-bla-bla" > /mnt/fs/out.txt
>> execve("/bin/echo", ["echo", "bla-bla-bla"], [/* 22 vars */]) = 0
>
> If you want an strace of the internal echo, you have to do it this
> way:
>
> # strace bash -c 'echo "bla-bla-bla" > /mnt/fs/out.txt'
>
> In fact it's the redirection whose failure you really care about.
The redirection itself won't fail, unless the device is out of inodes.
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."
Re: Internal 'echo' command doesn't handle I/O errors on close file
On Mon, Apr 23, 2012 at 06:50:31PM +0200, Andreas Schwab wrote: > The redirection itself won't fail, unless the device is out of inodes. Ah... OK, I can see how that might be the case. Or depending on the file system implementation, it might fail if an additional block of disk space would need to be allocated to the directory to hold the new filename. Which should be somewhat rare in practice.
Re: [patch] fix building when readline is disabled
On 4/23/12 12:22 AM, Mike Frysinger wrote: > if you disable readline, the complete.def code fails to build. simple patch > below (not sure if it's correct, but at least gets the conversation going). How did you disable readline? Running configure --disable-readline and building as usual works for me. You might want to run `make clean' before rebuilding. 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: [patch] fix building when readline is disabled
On Monday 23 April 2012 18:57:05 Chet Ramey wrote:
> On 4/23/12 12:22 AM, Mike Frysinger wrote:
> > if you disable readline, the complete.def code fails to build. simple
> > patch below (not sure if it's correct, but at least gets the
> > conversation going).
>
> How did you disable readline? Running configure --disable-readline and
> building as usual works for me. You might want to run `make clean' before
> rebuilding.
i suspect you have readline files still being included and it appears to work.
let's look at vanilla bash-4.2:
$ tar xf bash-4.2.tar.gz
$ cd bash-4.2
$ ./configure --disable-readline
$ make
...
rm -f complete.o
./mkbuiltins -D . complete.def
gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I.-g
-O2 complete.c || ( rm -f complete.c ; exit 1 )
rm -f complete.c
...
so, let's go into that dir and run it by hand:
$ cd builtins
$ ./mkbuiltins -D . complete.def
$ strace -f -eopen gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include
-I../lib -I.-g -O2 complete.c |& grep readline.h
...
[pid 12453] open("../lib/readline/readline.h", O_RDONLY|O_NOCTTY) = 4
...
if you were to clean out your readline code first, you'd see the build error
i'm seeing instead of the local readline code getting implicitly used even
though it was explicitly disabled.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [patch] fix building when readline is disabled
On 4/23/12 7:40 PM, Mike Frysinger wrote:
> On Monday 23 April 2012 18:57:05 Chet Ramey wrote:
>> On 4/23/12 12:22 AM, Mike Frysinger wrote:
>>> if you disable readline, the complete.def code fails to build. simple
>>> patch below (not sure if it's correct, but at least gets the
>>> conversation going).
>>
>> How did you disable readline? Running configure --disable-readline and
>> building as usual works for me. You might want to run `make clean' before
>> rebuilding.
>
> i suspect you have readline files still being included and it appears to work.
OK, so you've stripped the local readline copy out of the source tree?
Then configured it to build with a system readline library installation
that you remove?
> let's look at vanilla bash-4.2:
> $ tar xf bash-4.2.tar.gz
> $ cd bash-4.2
> $ ./configure --disable-readline
> $ make
> ...
> rm -f complete.o
> ./mkbuiltins -D . complete.def
> gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I.
> -g -O2 complete.c || ( rm -f complete.c ; exit 1 )
> rm -f complete.c
> ...
>
> so, let's go into that dir and run it by hand:
> $ cd builtins
> $ ./mkbuiltins -D . complete.def
> $ strace -f -eopen gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I..
> -I../include -I../lib -I.-g -O2 complete.c |& grep readline.h
> ...
> [pid 12453] open("../lib/readline/readline.h", O_RDONLY|O_NOCTTY) = 4
> ...
>
> if you were to clean out your readline code first, you'd see the build error
> i'm seeing instead of the local readline code getting implicitly used even
> though it was explicitly disabled.
What does "clean out your readline code" mean? Disabled means that it
doesn't end up in the resulting binary, and the bash binary is not linked
against readline. There aren't any link errors because the builtins are
in a library, and no other bash code calls any function in complete.c, so
complete.o is not linked out of libbuiltins.a. What kind of "build error"
are you seeing?
--
``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: [patch] fix building when readline is disabled
On Monday 23 April 2012 20:08:26 Chet Ramey wrote:
> On 4/23/12 7:40 PM, Mike Frysinger wrote:
> > On Monday 23 April 2012 18:57:05 Chet Ramey wrote:
> >> On 4/23/12 12:22 AM, Mike Frysinger wrote:
> >>> if you disable readline, the complete.def code fails to build. simple
> >>> patch below (not sure if it's correct, but at least gets the
> >>> conversation going).
> >>
> >> How did you disable readline? Running configure --disable-readline and
> >> building as usual works for me. You might want to run `make clean'
> >> before rebuilding.
> >
> > i suspect you have readline files still being included and it appears to
> > work.
>
> OK, so you've stripped the local readline copy out of the source tree?
yes
> Then configured it to build with a system readline library installation
> that you remove?
the system doesn't have readline at all
> > let's look at vanilla bash-4.2:
> > $ tar xf bash-4.2.tar.gz
> > $ cd bash-4.2
> > $ ./configure --disable-readline
> > $ make
> > ...
> > rm -f complete.o
> > ./mkbuiltins -D . complete.def
> > gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I.
> >-g -O2 complete.c || ( rm -f complete.c ; exit 1 ) rm -f complete.c
> > ...
> >
> > so, let's go into that dir and run it by hand:
> > $ cd builtins
> > $ ./mkbuiltins -D . complete.def
> > $ strace -f -eopen gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I..
> > -I../include -I../lib -I.-g -O2 complete.c |& grep readline.h ...
> > [pid 12453] open("../lib/readline/readline.h", O_RDONLY|O_NOCTTY) = 4
> > ...
> >
> > if you were to clean out your readline code first, you'd see the build
> > error i'm seeing instead of the local readline code getting implicitly
> > used even though it was explicitly disabled.
>
> What does "clean out your readline code" mean? Disabled means that it
> doesn't end up in the resulting binary, and the bash binary is not linked
> against readline. There aren't any link errors because the builtins are
> in a library, and no other bash code calls any function in complete.c, so
> complete.o is not linked out of libbuiltins.a. What kind of "build error"
> are you seeing?
without a readline.h header available (system or local copy), the build fails.
there's plenty of READLINE and HISTORY ifdefs in the other files, so this looks
like one place that got missed. imo, there should be no attempts to include a
readline header if support is disabled.
-mike
signature.asc
Description: This is a digitally signed message part.
