Solaris getcwd() implementation vs BASH

[Petr Sumbera]

Hi All,

Solaris doesn't implement getcwd() with support for dynamic allocation
of memory. This BASH consider as broken so that configure defines
GETCWD_BROKEN.

Later in bash-3.2/config-bot.h it disables HAVE_GETCWD completely:

/* If we have a getcwd(3), but it calls popen(), #undef HAVE_GETCWD so
   the replacement in getcwd.c will be built. */
#if defined (HAVE_GETCWD)  defined (GETCWD_BROKEN)
#  undef HAVE_GETCWD
#endif

This forces BASH on Solaris to use internal implementation of getcwd()
from bash-3.2/lib/sh/getcwd.c. Unfortunately this implementation has
some problems and fails (returns NULL) at very specific situation of
loop back mounting. It can be fixed but it would bring to this source
code not very nice platform specific code.

Much more easier is to use Solaris native implementation of getcwd()
which works at all cases correctly. Please consider following patch for
bash 3.0 (where I did the testing) as something for beginning of 
discussion (I don't know the history of the whole thing):


--- bash-3.0/builtins/common.c.orig Tue Jan 16 07:23:51 2007
+++ bash-3.0/builtins/common.c  Tue Jan 16 07:25:08 2007
@@ -472,7 +472,11 @@

   if (the_current_working_directory == 0)
 {
+#if defined(GETCWD_BROKEN)
+  the_current_working_directory = getcwd (0, PATH_MAX);
+#else
   the_current_working_directory = getcwd (0, 0);
+#endif
   if (the_current_working_directory == 0)
{
  fprintf (stderr, _(%s: error retrieving current directory:
%s: %s\n),
--- bash-3.0/config-bot.h.orig  Tue Jan 16 07:23:35 2007
+++ bash-3.0/config-bot.h   Tue Jan 16 07:24:52 2007
@@ -70,11 +70,13 @@
 #  define TERMIOS_MISSING
 #endif

+#if 0
 /* If we have a getcwd(3), but it calls popen(), #undef HAVE_GETCWD so
the replacement in getcwd.c will be built. */
 #if defined (HAVE_GETCWD)  defined (GETCWD_BROKEN)
 #  undef HAVE_GETCWD
 #endif
+#endif

 #if !defined (HAVE_DEV_FD)  defined (NAMED_PIPES_MISSING)
 #  undef PROCESS_SUBSTITUTION


---

Any comments are welcomed.

Thanks,

Petr




___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Quoting near =~ is inconsistent

[Tim Waugh]

Further to this, I am having trouble porting existing scripts to
bash-3.2's new style of regex matching.

Here is one example that is problematic: I want to use a character class
in my regex, but bash seems to get confused by the ':]]' closing the
class, and apparently takes it as a ']]' closing the conditional
expression.

Here is a distilled test case:

[[ $line =~ [[:space:]]*(a)?b ]]  echo match || echo no match

I used single quotes around the RHS in bash-3.1, which worked very well.
How should this be written so as to work with bash-3.2 -- and, of
course, still with bash-3.1?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Open file descriptors

[Richard Ray]

Other than lsof is there a way to determine what file descriptors are 
open?


Thanks
Richard


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Open file descriptors

[Matthew Woehlke]

Richard Ray wrote:

Other than lsof is there a way to determine what file descriptors are open?


I very much doubt there is a portable way, if that's what you're 
asking... On Linux there is also /proc/fd, I think?


--
Matthew
What a wonderful smell you've discovered! -- Princess Leia Organa



___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash

Re: Open file descriptors

[Andreas Schwab]

Richard Ray [EMAIL PROTECTED] writes:

 Other than lsof is there a way to determine what file descriptors are
 open?

$ (exec 4$n) 2/dev/null  echo fd $n is open

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash