Re: read it immediately
Norman Virus Control a supprimé le message original qui contenait le virus [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Question about Xterm title
Serge Koksharov schrieb am 13.02.2005 um 22:52:28 (+0300):
> Hello, dear all!
>
> I am bash v3.0 user. Often I need to run long-lived foreground tasks and I
> wish the name of the task with its arguments to be shown in the Xterm title.
> Much like preexec() function from zsh. I'm very happy with bash, and don't
> want to change my shell, but I'm badly need this feature. I haven't found any
> clues in documentation of bash how to achieve this. May be I missed
> something? Thank you!
Hello,
you can change the title with this command (if the term supports it):
echo -en "\033]0;--- $HOSTNAME $TERM $$ ---\007"
^^
google(xterm-control sequences)
==> http://www.kitebird.com/csh-tcsh-book/ctlseqs.pdf
==> http://www.xfree86.org/snapshot/ctlseqs.html
greetings,
Alexander Elgert
PS: I've created a shell function for myself to do check if it is an
xterm and interactive.
title is a function
title ()
{
title=$1;
interactive && [ "$TERM" = "xterm" ] && echo -en "\033]0;[EMAIL PROTECTED]"
}
interactive is a function
interactive ()
{
case "$-" in
*i*)
return 0
;;
*)
return 2
;;
esac
}
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Question about Xterm title
Serge Koksharov schrieb am 18.02.2005 um 06:32:52 (+0300): > On Thu, Feb 17, 2005 at 04:12:49PM +0100, Al Elgert wrote: > > Hello, > > > > you can change the title with this command (if the term supports it): > > > > echo -en "\033]0;--- $HOSTNAME $TERM $$ ---\007" > > ^^ > > May be I'm don't explained clearly enough. I need dynamic title, not static. > For example, I type: > $some_ncurses_appname -arg1 -arg2 > And after I pressed enter key I want xterm title changed to: > "-=xterm=- myhost.mydomain: some_ncurses_appname -arg1 -arg2". > > zsh uses preexec() builtin function to accomplish this - a function which is > just before a command is executed, and I haven't found any way to do this in > bash. Look at http://www.tldp.org/HOWTO/Xterm-Title-6.html if I'm again not > described my problem clearly enough. (Sorry, I overread the preexec part.) So your problem is not to set a title in xterm. Your problem is that PROMPT_COMMAND is applied _after_ the execution of the command. Do you want something like this? .inputrc: "\C-m": "\C-apreexec \n" accept-line I do not know a better way to do this in bash, Sorry. greetings Alexander ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Re[7]: Subshell exit trap is not invoked if shell exit trap also set
Konstantin,
I also tried to replicate on CentOS (under Fusion), but get the two
expected trap messages when killing the internal process:
ext pid=25449
int pid=25450
int exit trap in 25450
subshell done
ext exit trap in 25449
Test install:
- CentOS Linux release 7.2.1511 (Core) [under VMware Fusion]
- kernel-3.10.0-327.el7.x86_64; glibc 2.17
- GNU bash, version 5.0.3(1)-release
Al
On Tue, Mar 26, 2019 at 3:24 PM Konstantin Andreev
wrote:
> As you decide.
>
> Debian (working), subshell syscall trace on receiving sigterm:
>
> | $ strace -p 1436
> | strace: Process 1436 attached
> | wait4(-1, 0x7ffd49d66b90, 0, NULL) = ? ERESTARTSYS (To be restarted
> if SA_RESTART is set)
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1461,
> si_uid=1000} ---
> | rt_sigreturn({mask=[CHLD]}) = -1 EINTR (Interrupted system
> call)
> | rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
> | getpid()= 1436
> | write(1, "int exit trap in 1436\n", 22) = 22
> | rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[],
> sa_flags=SA_RESTORER, sa_restorer=0x7f3bbdc8b940},
> {sa_handler=0x5644f7bf6f40, sa_mask=[HUP INT ILL TRAP ABRT BUS FPE USR1
> SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM SYS], sa_flags=SA_RESTORER,
> sa_restorer=0x7f3bbdc8b940}, 8) = 0
> | getpid()= 1436
> | kill(1436, SIGTERM) = 0
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1436,
> si_uid=1000} ---
> | +++ killed by SIGTERM +++
>
> Centos (not working):
>
> | $ strace -p 90700
> | Process 90700 attached
> | wait4(-1, 0x7ffd77995430, 0, NULL) = ? ERESTARTSYS (To be restarted
> if SA_RESTART is set)
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=90617,
> si_uid=1000} ---
> | +++ killed by SIGTERM +++
>
> Regards, Konstantin.
>
> Chet Ramey, 26 Mar 2019 21:16 MSK:
> >
> > Run a system call tracer, I suppose. That will tell you the order in
> which things happen when the processes are traced, at least.
> >
> > Chet
>
> Konstantin Andreev, 26 Mar 2019 19:44 MSK:
> >
> > bash-5.0.3,
> > Just built and tested it. The systems are x86-64.
> >
> > + Debian GNU/Linux buster/sid (pre-10): works (both exit traps are
> invoked)
> > - CentOS Linux 7.2.1511:NOT work (subshell exit trap is NOT
> invoked)
> > - Oracle Solaris 11.3: NOT work (subshell exit trap is NOT
> invoked)
> >
> > What can I do to help you isolate this issue?
>
>
Re: Using Source within Binary Shell Scripts
On Wed, Mar 27, 2019 at 09:09:37AM -0700, Eduardo Bustamante wrote: > On Wed, Mar 27, 2019 at 8:17 AM Jason Hall wrote: > (...) > > The point is, their is a legitimate use for sourcing Binary Shell > > Scripts (...) > > Is it really a legitimate use? If you're doing it for "security" (by > obscurity I guess?), it's easy to defeat. The original message reads like Jason is attempting to defeat the 'security' on a self-decrypting script by using source to add the script's variables to the current shell so their values can be viewed. Better ways to do this is a question for the help list. It's not a bug. Al
Re: Leaking file descriptors on fast SIGINT's in PROMPT_COMMAND, PS1
On Sat, Apr 13, 2019 at 03:19:17PM -0400, Chet Ramey wrote: > On 3/28/19 8:01 AM, Tycho Kirchner wrote: > > the *interactive* bash leaks (pipe-)file-descriptors when fast interrupts > > (SIGINT) occur. The bug occurs on all bash-versions tested (see below), > > including 5.0.2(1)-release. > > I don't see any issue on Mac OS X. > I can reproduce the problem as described on Mac OS here. After starting the while loop, switch back to the first session (that is now scrolling with the SIGINGs) and hold ctrl-c. "leaking fds" appears fairly quickly and /dev/fd for the affected session does show several new descriptors remaining after breaking out of the while loop. The same goes for Fedora and CentOS for the versions of Bash Tycho listed. Al
