[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

2017-07-23 Thread Michael Cahill 
Follow-up Comment #6, bug #49466 (project findutils):

This issue appears to be fixed: it no longer reproduces for me with macOS
10.12.6.  I suspect it was caused by the same underlying behavior change to
poll described here: https://github.com/curl/curl/issues/1057 (fixed in
10.12.2).


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: findutils 4.6.0 v. Tru64 (strftime() v. "%F"?)

2017-07-23 Thread Bruno Haible 
James Youngman wrote:
> I'd need to update the
> gnulib version so one which offers nstrftime (instead of the old name)

This gnulib module is now called 'nstrftime'.

Bruno

[bug #51151] [wishlist] xargs -o support for interactive commands

2017-07-23 Thread Thorsten Glaser 
Follow-up Comment #13, bug #51151 (project findutils):

James, can *you* remember to type that?

I consider myself good in shell (after all, I maintain one), and still it took
three times to type that from memory right, and that was *after* reading in
the GNU documentation to use this form.

Plus there’s prior art in the BSDs, and adding this for compatibility and
easiness doesn’t hurt anyone.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

2017-07-23 Thread James Youngman 
Follow-up Comment #5, bug #49466 (project findutils):

Could you provide a system call trace?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: findutils 4.6.0 v. Tru64 (strftime() v. "%F"?)

2017-07-23 Thread James Youngman 
On Thu, May 25, 2017 at 10:04 PM, Paul Eggert  wrote:
> On 05/25/2017 07:54 AM, Eric Blake wrote:
>>
>> So yes, either findutils should be using nstrftime() and not strftime()
>> (which will guarantee that these sequences work), or it is indeed time
>> to patch gnulib to provide a replacement strftime() on platforms that
>> are not POSIX-compliant (and then still patch findutils to use the newer
>> gnulib).
>>
>> It's actually probably easier it findutils just starts using
>> nstrftime(), regardless of what else gnulib does, but it's at least
>> pointing out that gnulib should be documenting the known pitfalls in
>> native strftime() implementations.
>
>
>
> Yes to changing findutils to use nstrftime, and to documenting strftime
> gotchas in Gnulib.
>
> Not sure if it's worth wasting people's time writing a replacement strftime.
> nstrftime provides more functionality and should be more portable.

I'm OK with moving findutils to nstrftime.   I'd need to update the
gnulib version so one which offers nstrftime (instead of the old name)
but it's a good idea to do that anyway.

However, there is a simple replacement for %F (%Y-%m-%d); do we
currently know of any other reason to move findutils to nstrftime?

James.

Re: findutils 4.6.0 v. Tru64 (strftime() v. "%F"?)

2017-07-23 Thread James Youngman 
Please try the attached patch, which should fix the problem with %F on
Tru64 and on HP-UX.
From 95816b29d46fb6b64754d4a66e7d918b3f134a1f Mon Sep 17 00:00:00 2001
From: James Youngman 
Date: Sun, 23 Jul 2017 22:19:42 +0100
Subject: [PATCH] find: avoid strftime's non-portable %F specifier.
To: findutils-patc...@gnu.org

* find/print.c (format_date): Avoid passing %F to strftime since
some implementation lack it.  Pass the synonymous %Y-%m-%d
instead.  This fixes a bug manifesting on HP Tru64 UNIX V5.1B.
Reported by Steven M. Schweda .
---
 find/print.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/find/print.c b/find/print.c
index db6155c9..682197f4 100644
--- a/find/print.c
+++ b/find/print.c
@@ -631,7 +631,11 @@ format_date (struct timespec ts, int kind)
   /* Format the main part of the time. */
   if (kind == '+')
 {
-  strcpy (fmt, "%F+%T");
+  /* Avoid %F, some Unix versions lack it.  For example:
+ HP Tru64 UNIX V5.1B (Rev. 2650); Wed Feb 17 22:59:59 CST 2016
+ Also, some older HP-UX versions expand %F as the full month (like %B).
+ Reported by Steven M. Schweda  */
+  strcpy (fmt, "%Y-%m-%d+%T");
   need_ns_suffix = 1;
 }
   else
-- 
2.11.0

[bug #51151] [wishlist] xargs -o support for interactive commands

2017-07-23 Thread James Youngman 
Follow-up Comment #12, bug #51151 (project findutils):

I've read the discussion but I don't understand what's wrong with this
approach:

git grep -l -z foo | xargs -0 sh -c 'jupp "$@" < /dev/tty' jupp

This doesn't need "xargs -o" and is not specific to any shell implementation. 
 There is talk in this bug report about problems with "sh -c ... --" but that
construct ("--") is not used or needed.

So, can someone please explain what's wrong with "http://savannah.gnu.org/bugs/?51151>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51506] Better support for data processing with basenames

2017-07-23 Thread James Youngman 
Update of bug #51506 (project findutils):

Severity:  3 - Normal => 1 - Wish   
  Status:None => Wont Fix   
 Assigned to:None => jay
 Open/Closed:Open => Closed 

___

Follow-up Comment #13:

I recommend using an approach such as the one suggested by Bernhard.

We're not going to change the behaviour of -print because this would make the
resulting executable fail to comply with POSIX.  We're not going to
create/build an an alternate executable with a different meaning of -print
because distributions won't include it anyway (they don't include the existing
alternate binary "oldfind" which we already have).

Consider "find" from a user-interface point of view.  It already has too many
options, primitives, tests etc.   The manual (both Texinfo and man) is large. 
Every additional option is a burden in maintenance (of tests, of the
implementation code, and of documentation).  For these reasons we apply a high
bar to the creation of new features.   Higher still for features whose
underlying use-case can easily be achieved by the use of _existing_ features
of find.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: is slocate database still new?

2017-07-23 Thread James Youngman 
On Sun, Jul 16, 2017 at 6:49 PM, Igor Fontana  wrote:
> EHLO,
>
> im running 4.6.0 and im getting this:
>
> glocate: ‘/var/lib/locate/locatedb’ is an slocate database.  Support
> for these is new, expect problems for now.
> glocate: ‘/var/lib/locate/locatedb’ is an slocate database.  Turning
> on the '-e' option.
[...]
> so is it really new? wat should i be worried about? leaking private paths?

You are quite right, the warning message is quite obsolete.  I added
it in 2006 (commit c28788c0) and didn't remember to remove it.   Sorry
about that.   I have removed the warning (just now, so the next
release won't warn about this).

James.

Re: is slocate database still new?

2017-07-23 Thread Bernhard Voelker 
On 07/19/2017 06:46 PM, Igor Fontana wrote:
> 4.6.0 is from 2015 and is teh latest release so far. waiting for teh next! ty 
> <3

your point.  Let's see if we can do a release in the next 1-2 months.

Have a nice day,
Berny