SHELL env not exported in bash
When I start the Cygwin bash shell
with the Cygwin installed procedure
the the SHELL env var is not exported.
(sh started from within bash,
or replacing bash in cygwin.bat,
does not even have a SHELL variable).
The simple program below
can check this:
<<<>>>
#include
int
main ()
{
char *shellenv;
shellenv = getenv("SHELL");
printf ("SHELL is '%s'", shellenv);
return 0;
}
<<<>>>
gcc -o testshellenv testshellenv.c
If I run ./testshellenv I get:
SHELL is '(null)'
If I enter
export SHELL
at bash prompt
then
./testgetenv returns:
SHELL is '/bin/bash'
Trying the same program on a remote linux machine
gives '/bin/bash' directly, but this is no real
proof as connecting to my local account with ssh
also results in a bash shell where SHELL envvar is exported.
I can't test on a local Linux machine, sorry.
So my basic question is:
is it intended behavior that SHELL
env variable is not exported when cygwin bash
is run locally?
This problem arises from the fact that one of the latest cygwin specific
GDB patch does make use of getenv("SHELL")
and I was rather surprised by the null result that I got here.
Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:[EMAIL PROTECTED]
Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Cygwin strange behavior report
0xC4, res 1 [sig] bash setup_handler: good. Didn't suspend main thread, th 0x610A4420 [sig] bash setup_handler: returning 1 [sig] bash sig_handle: returning 1 - [sig] bash wait_sig: set main thread completion event - [sig] bash wait_sig: looping - [main] bash sig_send: Waiting for thiscomplete 0xEC [main] bash sig_send: returning 0 from sending signal -2 [main] bash reset_signal_arrived: reset signal_arrived [main] bash set_process_mask: old mask = 0, new mask = 2 --- 128,137 [sig] bash proc_subproc: clear waiting threads [sig] bash proc_subproc: finished clearing [sig] bash proc_subproc: returning 1 ! [sig] bash interrupt_setup: armed signal_arrived 0xDC, res 1 [sig] bash setup_handler: good. Didn't suspend main thread, th 0x610A4420 [sig] bash setup_handler: returning 1 [sig] bash sig_handle: returning 1 [main] bash sig_send: returning 0 from sending signal -2 [main] bash reset_signal_arrived: reset signal_arrived [main] bash set_process_mask: old mask = 0, new mask = 2 *** *** 134,142 [main] bash set_process_mask: old mask = 3A0002, new mask = 2 [main] bash set_process_mask: old mask = 2, new mask = 0 [main] bash set_process_mask: old mask = 0, new mask = 0 ! [main] bash set_process_mask: not calling sig_dispatch_pending. sigtid 0x868 current 0x494 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 [main] bash set_process_mask: old mask = 0, new mask = 3A [main] bash set_process_mask: old mask = 3A, new mask = 0 [main] bash sigaction: signal 2, newact 0x22F4F4, oldact 0x22F4E4 --- 139,149 [main] bash set_process_mask: old mask = 3A0002, new mask = 2 [main] bash set_process_mask: old mask = 2, new mask = 0 [main] bash set_process_mask: old mask = 0, new mask = 0 ! [main] bash set_process_mask: not calling sig_dispatch_pending. sigtid 0x388 current 0x828 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 + [sig] bash wait_sig: set main thread completion event + [sig] bash wait_sig: looping [main] bash set_process_mask: old mask = 0, new mask = 3A [main] bash set_process_mask: old mask = 3A, new mask = 0 [main] bash sigaction: signal 2, newact 0x22F4F4, oldact 0x22F4E4 *** *** 167,173 [main] bash sigaction: signal 28, newact 0x4785A0, oldact 0x22F4D4 [main] bash sigaction: signal 2, newact 0x22F4F4, oldact 0x22F4E4 [main] bash set_process_mask: old mask = 0, new mask = 0 ! [main] bash set_process_mask: not calling sig_dispatch_pending. sigtid 0x868 current 0x494 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 [main] bash set_process_mask: old mask = 0, new mask = 3A [main] bash set_process_mask: old mask = 3A, new mask = 0 --- 174,180 [main] bash sigaction: signal 28, newact 0x4785A0, oldact 0x22F4D4 [main] bash sigaction: signal 2, newact 0x22F4F4, oldact 0x22F4E4 [main] bash set_process_mask: old mask = 0, new mask = 0 ! [main] bash set_process_mask: not calling sig_dispatch_pending. sigtid 0x388 current 0x828 [main] bash sigaction: signal 2, newact 0x22FE14, oldact 0x22FE04 [main] bash set_process_mask: old mask = 0, new mask = 3A [main] bash set_process_mask: old mask = 3A, new mask = 0 Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:[EMAIL PROTECTED] Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New snapshot with significant new functionality
At 08:15 02/05/2002 , [EMAIL PROTECTED] a écrit: >No problems, but is all the following expected behaviour? Having >uncompressed the new .dll and copied it to /bin: > >1. had to make /proc using mkdir /proc > >2. ls -al / doesn't actually show /proc > >3. ls -al /proc shows (something like) > >dr-xr-xr-x 10 0medicine0 Jan 1 1970 1951627 >dr-xr-xr-x 10 0medicine0 Jan 1 1970 2022611 >dr-xr-xr-x7 0medicine0 May 2 07:11 registry >-r--r--r--1 0medicine0 May 2 07:11 uptime >-r--r--r--1 0medicine0 May 2 07:11 version > >4. Note lack of . and .. > >5. ls -al /proc/1951627 shows a lot of stuff, but > >6. ls -al /proc/2022611 gives >ls: /proc/2022611: No such file or directory This is probably just because that one is the entry for the 'ls -al /proc' itself, and thus is invalid after end of execution of 'ls -al /proc'. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:[EMAIL PROTECTED] Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[BUG] Patch.exe problem report
I already mentioned the following bug some time ago, but I now took the time to identify the problem. The problem appears if you are using patch to apply a patch on a binary mounted device while your patch uses a temporary directory that is located on a text mounted dir. The temprary file is that created as /temp/dir/ poX where the XXX are replaced by a number. But the file is opened without O_BINARY flag. After the patch is applied, the patch code tries to move the file, which fails with EXDEV err, which seems OK as they are on different partition, but after that the use copy_file function, which does copy the file using O_BINARY file. This results in a unix mode source file on which you apply a unix mode patch, will be written as text in the temporary directory, and thus in Dos mode with CR/LF, and finally copied back to the binary mounted dir. I hope that my explanation of the problem is clear enough. It seems to be a consequence of the apparently innocent assumption that on a given OS, a copy of a text file from one dir to another dir can be done using O_BINARY. But this assumption is false for cygwin. I didn't really find a good solution to this problem yet... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:[EMAIL PROTECTED] Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gdb in xfree86: ^C
ipt 6.51-1 gperf 0.0 grep2.4.2-1 groff 1.17.2-1 gzip1.3.2-1 inetutils 1.3.2-17 irc 20010101-1 jbigkit 1.2-6 jpeg6b-7 less358-3 libintl 0.10.38-3 libintl10.10.40-1 libncurses5 5.2-1 libncurses6 5.2-8 libpng 1.0.12-1 libpng2 1.0.12-1 libreadline44.1-2 libreadline54.2a-1 login 1.4-3 lynx2.8.4-1 m4 0.0 make3.79.1-5 man 1.5g-2 mingw 20010917-1 mingw-runtime 1.2-1 mktemp 1.4-1 mt 2.0.1-1 mutt1.2.5i-6 ncftp 3.0.2-2 ncurses 5.2-8 newlib-man 20001118-1 opengl 1.1.0-5 openssh 3.0.2p1-5 openssl 0.9.6c-3 patch 2.5-2 patch-src 2.5-2 pcre3.7-1 perl5.6.1-2 popt1.6.2-1 postgresql 7.1.3-2 python 2.2-1 readline4.2a-1 regex 4.4-2 rsync 2.5.1-2 rxvt2.7.2-9 sed 3.02-1 sh-utils2.0-2 squid 2.4-STABLE20010508 ssmtp 2.38.7-3 tar 1.13.19-1 tcltk 20001125-1 tcsh6.11.00-3 termcap 20010825-1 terminfo5.2-1 tetex-beta 20001218-1 texinfo 4.0-5 textutils 2.0.16-1 tiff3.5.6beta-2 time1.7-1 unzip 5.41-1 vim 6.0.93-1 w32api 1.2-1 wget1.8-1 which 1.5-1 xpm-nox 4.2.0-1 zip 2.3-1 zlib1.1.3-7 Use -h to see help about each section Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:[EMAIL PROTECTED] Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
