Re: set0 builtin

[Masatake YAMATO]

I got no answer, so I'll send again.


Hi,

To improve bashdb, a bash debugger, we submitted two patches to bash,
adding readfile builtin and removing bashdb.el ever. I hope you don't
forget it:)

We would like submit one more patch, adding set0 builtin.

The purpose of set0 in the debugger is that users often write programs
that refer to $0. For example to display a usage string or maybe they
change the behavior based on how they were called. So this helps in
making these programs act the same way and gives an alternative to
invoking with "bash --debugger".

The patch is for the latest bash-3.2 patch level 039.
We hope set0 is included in next version of bash.

Regards,
Masatake YAMATO

diff -ruN bash-3.2-patched/builtins/Makefile.in 
bash-3.2-work/builtins/Makefile.in
--- bash-3.2-patched/builtins/Makefile.in   2006-03-08 04:42:33.0 
+0900
+++ bash-3.2-work/builtins/Makefile.in  2008-09-17 20:09:33.0 +0900
@@ -121,7 +121,7 @@
$(CC) -c $(CCFLAGS) $<
 
 DEFSRC =  $(srcdir)/alias.def $(srcdir)/bind.def $(srcdir)/break.def \
- $(srcdir)/builtin.def $(srcdir)/caller.def \
+ $(srcdir)/builtin.def $(srcdir)/caller.def $(srcdir)/set0.def \
  $(srcdir)/cd.def $(srcdir)/colon.def \
  $(srcdir)/command.def $(srcdir)/declare.def $(srcdir)/echo.def \
  $(srcdir)/enable.def $(srcdir)/eval.def $(srcdir)/getopts.def \
@@ -140,7 +140,7 @@
getopt.h 
 
 OFILES = builtins.o \
-   alias.o bind.o break.o builtin.o caller.o cd.o colon.o command.o \
+   alias.o bind.o break.o builtin.o caller.o set0.o cd.o colon.o command.o 
\
common.o declare.o echo.o enable.o eval.o evalfile.o \
evalstring.o exec.o \
exit.o fc.o fg_bg.o hash.o help.o history.o jobs.o kill.o let.o \
@@ -243,6 +243,7 @@
 break.o: break.def
 builtin.o: builtin.def
 caller.o: caller.def
+set0.o: set0.def
 cd.o: cd.def
 colon.o: colon.def
 command.o: command.def
@@ -362,6 +363,12 @@
 caller.o: $(topdir)/shell.h $(topdir)/syntax.h $(topdir)/unwind_prot.h 
$(topdir)/variables.h $(topdir)/conftypes.h
 caller.o: $(srcdir)/common.h $(BASHINCDIR)/maxpath.h ./builtext.h
 caller.o: ${BASHINCDIR}/chartypes.h $(topdir)/bashtypes.h
+set0.o: $(topdir)/command.h ../config.h $(BASHINCDIR)/memalloc.h
+set0.o: $(topdir)/general.h $(topdir)/xmalloc.h $(topdir)/quit.h 
$(topdir)/dispose_cmd.h
+set0.o: $(topdir)/make_cmd.h $(topdir)/subst.h $(topdir)/externs.h
+set0.o: $(topdir)/shell.h $(topdir)/syntax.h $(topdir)/unwind_prot.h 
$(topdir)/variables.h $(topdir)/conftypes.h
+set0.o: $(srcdir)/common.h $(BASHINCDIR)/maxpath.h ./builtext.h
+set0.o: ${BASHINCDIR}/chartypes.h $(topdir)/bashtypes.h
 cd.o: $(topdir)/command.h ../config.h $(BASHINCDIR)/memalloc.h 
$(topdir)/error.h
 cd.o: $(topdir)/general.h $(topdir)/xmalloc.h $(topdir)/quit.h 
$(topdir)/dispose_cmd.h
 cd.o: $(topdir)/make_cmd.h $(topdir)/subst.h $(topdir)/externs.h
@@ -591,6 +598,7 @@
 bind.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
 break.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
 caller.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
+set0.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
 cd.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
 common.c: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
 complete.o: ${topdir}/bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
diff -ruN bash-3.2-patched/builtins/set0.def bash-3.2-work/builtins/set0.def
--- bash-3.2-patched/builtins/set0.def  1970-01-01 09:00:00.0 +0900
+++ bash-3.2-work/builtins/set0.def 2008-09-17 20:31:42.0 +0900
@@ -0,0 +1,82 @@
+This file is caller.def, from which is created caller.c.  It implements the
+builtin "caller" in Bash.
+
+Copyright (C) 2008 Rocky Bernstein for Free Software Foundation, Inc.
+
+This file is part of GNU Bash, the Bourne Again SHell.
+
+Bash is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 2, or (at your option) any later
+version.
+
+Bash is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License along
+with Bash; see the file COPYING.  If not, write to the Free Software
+Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA.
+
+$PRODUCES set0.c
+
+$BUILTIN set0
+$FUNCTION set0_builtin
+$DEPENDS_ON DEBUGGER
+$SHORT_DOC set0 STRING
+
+Set $0, the program name.
+$END
+
+#include 
+
+#include "../bashintl.h"
+
+#include "../shell.h"
+#include "common.h"
+
+#ifdef LOADABLE_BUILTIN
+#  include "builtins.h"
+#endif
+
+int 
+set0_builtin (WORD_LIST *list)
+{
+  /* Check parameters: there should be exactly one. */
+  if (list == 0) 
+{
+  builtin_error (_("An a

Re: Readline : move to previous/next path component

[Andre Majorel]

On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Andre Majorel wrote:
>> One frequently needed function that readline does not seem to
>> have is a way to move to the beginning of the next or previous
>> path component.
>
> Readline doesn't have any built-in knowledge of Unix pathnames.

For my edification, is the relative lack of Unix/shell support
due to
1. "can of worms",
2. "readline is supposed to be general",
3. "there is no need for it" ?

> You might want to take a look at emacs-mode M-b, which moves backward
> by strings of alphabetic characters, and M-f, which moves forward.
> You might have to play around with a macro that moves forward additional
> characters past the `/', but that should get you further.

Thanks, but that would be even worse. Instead of just breaking
down at the ends of pathnames, it will break every time a path
component contains a non-letter, which is often for me.

-- 
André Majorel http://www.teaser.fr/~amajorel/>
You measure democracy by the freedom it gives its dissidents, not
the freedom it gives its assimilated conformists -- Abbie Hoffman.

bash sometimes don't wait for children process

[Roman Rakus]

There is code in "execute_cmd.c" function "execute_command_internal":
...
#if defined (RECYCLES_PIDS)
   last_made_pid = NO_PID;
#endif
   last_pid = last_made_pid;
...
   if (already_making_children && pipe_out == NO_PIPE &&
   last_made_pid != last_pid)
 {
...
 exec_result = wait_for (last_made_pid);
 }

I'm wondering why we are doing assignment (last_pid = last_made_pid;) 
and then test it (&& last_made_pid != last_pid)?
I understand we create new child process and change last_made_pid. So, 
for example, we have last_pid 255, same as last_made_pid. Now we create 
child process and change last_made_pid to that new (256 probably). Now 
we test if they are same, they aren't and we wait for child. But what 
about situating where we have a lot of process'? 32768... last_pid will 
be 32768, make new child with pid 32769, we go through if, wait for 
child. Now we do next command, last_pid will change to 32769, create 
child, but this child will have pid 32769 and we don't go through if and 
don't wait to child.
It's done by kernel, but why is bash doing this check? Is it necessary? 
Isn't enough to check like this: if (already_making_children && pipe_out 
== NO_PIPE)? Or get a rid of #if defined (RECYCLES_PIDS) and do 
last_made_pid = NO_PID; every time? For me is better solution the 
lighter checking.

Re: why does bash not execute .bashrc with ssh -t ?

[Jon Seymour]

Chet,

Thanks for that info.

Due to the circumstances, recompiling bash isn't really an option for me, so
I decided to deal with it by having ssh invoke a script that could guarantee
~/.bashrc was sourced.

Regards,

jon seymour.

On Wed, Oct 15, 2008 at 1:24 PM, Chet Ramey <[EMAIL PROTECTED]> wrote:

> Jon Seymour wrote:
>
> > Bash attempts to determine when it is being run by the remote shell
> > daemon, usually rshd.  If bash determines it is being run by rshd, it
> > reads  and  executes
> > commands  from  ~/.bashrc,  if that file exists and is readable.  It
> > will not do this if invoked as sh.  The --norc option may be used to
> inhibit
> > this behavior, and
> > the --rcfile option may be used to force another file to be read, but
> > rshd does not generally invoke the shell with those options or allow them
> to
> > be specified.
> >
> > However, when I use the ssh -t option, it would seem that allocation of a
> > pseudo-tty is causing bash to assume that it is not being invoked by a
> > remote shell daemon.
>
> Correct.  One of the criteria bash uses to decide whether it's being
> invoked by rshd or sshd is that its stdin is a socket.  Allocating a
> pseudo-tty makes that false.
>
> You can force bash to source .bashrc when it finds the various ssh
> variables in its startup environment by defining SSH_SOURCE_BASHRC
> in config-top.h and rebuilding bash.  That will cause .bashrc to be
> sourced more times than it should, but it will catch the cases you
> are interested in.
>
> Chet
>
> >
> > Is there any way I can have an ssh pseudo-tty and get bash to execute
> > ~/.bashrc?
> >
> > jon seymour.
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
> Chet Ramey, ITS, CWRU[EMAIL PROTECTED]
> http://cnswww.cns.cwru.edu/~chet/ 
>

Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client

[Serge Dussud]

Hi Chet,

any follow-up on this ?

tia,
Serge



[..]




 From man page ld(1) (snv_99 box):


-B direct | nodirect

These options govern direct binding.  -B  direct  estab-
lishes direct binding information by recording the rela-
tionship between each symbol reference together with the
dependency  that  provides  the definition. In addition,
direct binding information is established  between  each
symbol reference and an associated definition within the
object being  created.  The  runtime  linker  uses  this
information to search directly for a symbol in the asso-
ciated object rather than to carry out a default  symbol
search.

Direct binding information can only  be  established  to
dependencies  specified  with  the  link-edit. Thus, you
should use the -z defs  option.  Objects  that  wish  to
interpose  on  symbols  in  a direct binding environment
should identify themselves as interposers  with  the  -z
interpose  option. The use of -B direct enables -z lazy-
load for all dependencies.

The -B nodirect option prevents any  direct  binding  to
the  interfaces offered by the object being created. The
object being created can continue to  directly  bind  to
external  interfaces by specifying the -z direct option.
See Appendix D, Direct Bindings, in Linker and Libraries
Guide.
.

-z interpose

Marks the object as an interposer. At runtime, an object
is  identified  as  an explicit interposer if the object
has been tagged using the -z interpose option. An expli-
cit  interposer  is  also  established when an object is
loaded using the LD_PRELOAD environment variable. Impli-
cit interposition can occur because of the load order of
objects, however, this implicit interposition is unknown
to the runtime linker. Explicit interposition can ensure
that interposition takes place regardless of  the  order
in which objects are loaded. Explicit interposition also
ensures that the runtime linker searches for symbols  in
any  explicit  interposers  when  direct bindings are in
effect.
.


Could it be the explanation and a possible solution ?

Serge









Thanks,
Serge



If it's documented that applications on Solaris may no longer link
with their own versions of malloc, that's fine -- I can arrange things
so that bash doesn't try to use it's internal malloc on Solaris 10
and 11.

Chet

Re: bash cores if nscd disabled on Solaris LDAP sasl/gssapi client

[Chet Ramey]

Serge Dussud wrote:
> 
> Hi Chet,
> 
> any follow-up on this ?

Haven't looked at it yet, sorry.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/

Re: "tcsetattr: Interrupted system call" after rapid-fire ^C chars

[Chet Ramey]

> And that sys_error message is, I believe, the exact error I am seeing.
> What I am wondering is how did I manage to invoke this by using ^C?  Did
> I hit some small window when readline was not running and when the
> program that would normally catch the kill signal was not listening
> (i.e. bash itself somehow caught it)?  I did not think this was
> possible.  Just wondering if this is something that should not happen.

The window's certainly there when the child exits and bash reaps it.  Once
the child dies and the terminal's foreground process group gets reset to
bash's, the shell will receive the SIGINTs generated by repeated ^C.  Bash
installs a signal handler for SIGINT, but the SIGINT will still interrupt
tcsetattr, especially if tcsetattr is called with TCSADRAIN.  (The code in
question is ensuring that a process that exits due to a signal won't leave
the terminal in an unusable state.  It's just one of the housekeeping things
that happens before readline is called to read the next command.)

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/

Re: Readline : move to previous/next path component

[Chet Ramey]

> On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote:
> > Andre Majorel wrote:
> >> One frequently needed function that readline does not seem to
> >> have is a way to move to the beginning of the next or previous
> >> path component.
> >
> > Readline doesn't have any built-in knowledge of Unix pathnames.
> 
> For my edification, is the relative lack of Unix/shell support
> due to
> 1. "can of worms",
> 2. "readline is supposed to be general",
> 3. "there is no need for it" ?

Mostly the second one, mixed with the fact that nobody's requested
this particular feature before.  Readline is very extensible; bash
adds quite a lot to the basic framework -- look at all the code in
bashline.c.  If you'd like to take a crack at writing a bindable
readline command to do what you want, I'd certainly look at it for a
future version.  (You'll probably get to it before I would.)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/

Re: bash sometimes don't wait for children process

[Chet Ramey]

> last_made_pid != last_pid)
>   {
> ...
>   exec_result = wait_for (last_made_pid);
>   }
> 
> I'm wondering why we are doing assignment (last_pid = last_made_pid;) 
> and then test it (&& last_made_pid != last_pid)?

To see if we created a process in execute_simple_command that we need
to wait for.  The presence of non-Unix systems that tend to recycle
pids quickly (or allocate at random from a small pool) makes the check
unreliable, so we call wait_for every time. 

> I understand we create new child process and change last_made_pid. So, 
> for example, we have last_pid 255, same as last_made_pid. Now we create 
> child process and change last_made_pid to that new (256 probably). Now 
> we test if they are same, they aren't and we wait for child. But what 
> about situating where we have a lot of process'? 32768... last_pid will 
> be 32768, make new child with pid 32769, we go through if, wait for 
> child. Now we do next command, last_pid will change to 32769, create 
> child, but this child will have pid 32769 and we don't go through if and 
> don't wait to child.

If you're saying that the kernel will keep giving out pid 32769 over and
over again as long as it's available when the next call to fork() comes in,
then that's reason enough to define RECYCLES_PIDS.  Bash assumes Unix
systems have a pid cycle of at least 16 bits and that pids increase until
wraparound.  Non-Unix systems like cygwin behave differently and prompted
the inclusion of the RECYCLES_PIDS code.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/

Re: Readline : move to previous/next path component

[Andre Majorel]

On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote:
>> On 2008-10-15, Chet Ramey <[EMAIL PROTECTED]> wrote:
>> > Andre Majorel wrote:
>> >> One frequently needed function that readline does not seem to
>> >> have is a way to move to the beginning of the next or previous
>> >> path component.
>> >
>> > Readline doesn't have any built-in knowledge of Unix pathnames.
>> 
>> For my edification, is the relative lack of Unix/shell support
>> due to
>> 1. "can of worms",
>> 2. "readline is supposed to be general",
>> 3. "there is no need for it" ?
>
> Mostly the second one, mixed with the fact that nobody's requested
> this particular feature before.  Readline is very extensible; bash
> adds quite a lot to the basic framework -- look at all the code in
> bashline.c.

OK. Unfortunately, the hackability appears to be at the source
level, not at the .inputrc level. For most Bash users,
maintaining your own binaries is inconvenient.

> If you'd like to take a crack at writing a bindable readline
> command to do what you want, I'd certainly look at it for a
> future version.  (You'll probably get to it before I would.)

I think the thing I've missed the most in readline, besides an
understanding of Unix pathnames, is an understanding of shell
quoting. Sometimes I'd like to be able to delete or move over
A\ Very\ Long\ Directory\ Name/A\ Very\ Long \ File\ Name or
'Another file name that'\''s got inverted commas in it' in one
operation.

character-search and character-search-backward sometimes help
but they're bound to ^] which cannot be entered at the Linux
console on an AZERTY keyboard.

Vi mode would help, but in Bash, there's no way to switch
between it and Emacs mode on the fly.

No time to look into it at the moment, but sooner or later,
frustration will win...

-- 
André Majorel http://www.teaser.fr/~amajorel/>
You measure democracy by the freedom it gives its dissidents, not
the freedom it gives its assimilated conformists -- Abbie Hoffman.

Puzzling discrepancy in bash variables

[RMMM]

I'm trying to create a bash function for use in auto completion, but
I've run into bash behavior I don't understand. All I want to do is
generate a list of the file names from a certain directory. I have a line

filenames=$(for file in `ls -1 mydir`; do echo -n "${file} " ; done )

This seems to produce the correct list:
bash> echo $filenames
resources doc src 
bash> 

However, it doesn't work with the compgen function:
bash> compgen -W "${filenames}" -- s
bash>



On the other hand, if I create the same variable manually, it works:
bash> filenames1="resources doc src "
bash> compgen -W "${filenames1}" -- s
src
bash>

As far as I can tell, the variables $filenames and $filenames1 have the same
values. Yet, they 
behave differently when used in an argument. Is there some hidden aspect to
a bash variable 
that I'm not seeing?



-- 
View this message in context: 
http://www.nabble.com/Puzzling-discrepancy-in-bash-variables-tp20003296p20003296.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: Puzzling discrepancy in bash variables

[RMMM]

RMMM wrote:
> 
> As far as I can tell, the variables $filenames and $filenames1 have the
> same values. Yet, they 
> behave differently when used in an argument. Is there some hidden aspect
> to a bash variable 
> that I'm not seeing?
> 

I just figured out the problem. I was running this in a shell with
dircolors. Arggg!

doing 
filenames=`ls --color=no mydir`
is all I needed to do. Well ... maybe there's some better way of getting the
filenames
that's immune to any invisible codes.




-- 
View this message in context: 
http://www.nabble.com/Puzzling-discrepancy-in-bash-variables-tp20003296p20003300.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.

Re: Puzzling discrepancy in bash variables

[Matthew Woehlke]

RMMM wrote:

RMMM wrote:

As far as I can tell, the variables $filenames and $filenames1 have the
same values. Yet, they 
behave differently when used in an argument. Is there some hidden aspect
to a bash variable 
that I'm not seeing?


I just figured out the problem. I was running this in a shell with
dircolors. Arggg!

doing 
filenames=`ls --color=no mydir`

is all I needed to do. Well ... maybe there's some better way of getting the
filenames
that's immune to any invisible codes.


Guess 1:
command ls # avoids aliases, I think?
\ls # similar
env ls # also similar

(note: I belive --color=no is default behavior, probably you have an 
alias that is adding --color=auto / --color=tty, which is why avoiding 
the alias should work)


Guess 2:
files="$( for f in mydir/* ; do echo -n "${f#mydir/} " ; done )"
# uses bash glob expansion instead of ls, probably faster to boot

Guess 3:
files="$( cd mydir ; echo * )"

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Time is an illusion. Lunchtime doubly so. -- Ford Prefect (Douglas 
Adams' HHGttG)

Re: Readline : move to previous/next path component

[Aharon Robbins]

In article <[EMAIL PROTECTED]>,
Andre Majorel  <[EMAIL PROTECTED]> wrote:
>Vi mode would help, but in Bash, there's no way to switch
>between it and Emacs mode on the fly.

Au contraire:

set -o vi
set -o emacs
-- 
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354Home Phone: +972  8 979-0381
Nof Ayalon  Cell Phone: +972 50  729-7545
D.N. Shimshon 99785 ISRAEL