Re: Buggy mv --interactive --reply=no, hopefully solved here
Vlada Macek [EMAIL PROTECTED] wrote:
I still believe there is a bug in `mv'. Try to run
mv --interactive --reply=no plain1 plain2
and given both plains exist, plain2 gets overwritten. This is not
expected behavior, not just by me (there is a Debian bug filled in).
Command `cp' is not affected.
The problem seems to be fixed by this:
--- coreutils-cvs/src/copy.c2005-04-11 22:06:34.0 +0200
+++ coreutils/src/copy.c2005-05-09 21:43:40.539405480 +0200
Thank you for the report and patch.
I've applied it, adjusted some comments, and added a test case.
The change is committed, but there will be some delay before
it reaches savannah.
2005-05-10 Jim Meyering [EMAIL PROTECTED]
* src/copy.c (abandon_move): Remove erroneous UNWRITABLE check.
This makes `mv -i --reply=no f1 f2' work as expected (in not
performing the move operation). But note that specifying `-i'
after `--reply=no' does *not* work.
Tiny patch from Vlada Macek.
Correct a comment.
* tests/mv/reply-no: New file. Test for the above fix.
* tests/mv/Makefile.am (TESTS): Add reply-no.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.179
retrieving revision 1.180
diff -u -p -u -r1.179 -r1.180
--- src/copy.c 11 Apr 2005 20:06:34 - 1.179
+++ src/copy.c 10 May 2005 07:35:43 - 1.180
@@ -798,8 +798,8 @@ record_file (Hash_table *ht, char const
/* When effecting a move (e.g., for mv(1)), and given the name DST_PATH
of the destination and a corresponding stat buffer, DST_SB, return
- true if the logical `move' operation should not proceed.
- Return true if it may proceed.
+ true if the logical `move' operation should _not_ proceed.
+ Otherwise, return false.
Depending on options specified in X, this code may issue an
interactive prompt asking whether it's ok to overwrite DST_PATH. */
static bool
@@ -808,8 +808,7 @@ abandon_move (const struct cp_options *x
struct stat const *dst_sb)
{
assert (x-move_mode);
- return ((x-interactive == I_ALWAYS_NO
-UNWRITABLE (dst_path, dst_sb-st_mode))
+ return (x-interactive == I_ALWAYS_NO
|| ((x-interactive == I_ASK_USER
|| (x-interactive == I_UNSPECIFIED
x-stdin_tty
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
On Mon, May 09, 2005, Paul Eggert wrote: Derek Price [EMAIL PROTECTED] writes: + myargv[[0]] = conftest; + myargv[[1]] = -+; This doesn't null-terminate myargv. D'oh ! But I still don't get why the change is needed. It sounds like you're assuming Solaris 11 getopt might get fixed? But even in that case, the current code will work, right, since it will use GNU getopt? So this is just an optimization for the hypothetical case if Solaris 11 getopt gets fixed? In that case perhaps we should wait for Solaris 11 and test it before installing this patch, as it's more likely to cause a bug than to fix one. Well, it might still fail on other OSes, that also do not use GNU getopt. They do probably also not have the getopt_clip. I'll check this on IRIX, today. (mk) -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 Im prämotorischen Cortex kann jeder ein Held sein. (bdw) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Make Check on coreutils, darwin failed
I am running macosx 10.4 with newly installed xcode tools. Make check failed. I am providing the first ~20 lines of config.log and the last ~50 lines of the output of 'make check.' Let me know if you want any other information. (I ran make install and everything seems to be working fine.) config.log ## - ## ## Platform. ## ## - ## hostname = New uname -m = Power Macintosh uname -r = 8.0.0 uname -s = Darwin uname -v = Darwin Kernel Version 8.0.0: Sat Mar 26 14:15:22 PST 2005; root:xnu-792.obj~1/RELEASE_PPC /usr/bin/uname -p = powerpc /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = Mach kernel version: Darwin Kernel Version 8.0.0: Sat Mar 26 14:15:22 PST 2005; root:xnu-792.obj~1/RELEASE_PPC Kernel configured for up to 2 processors. 2 processors are physically available. Processor type: ppc970 (PowerPC 970) Processors active: 0 1 Primary memory available: 2.25 gigabytes Default processor set: 93 tasks, 316 threads, 2 processors Load average: 0.32, Mach factor: 1.67 /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown ** The end of the output of make check is below: All 1 tests passed == Making check in tail-2 make check-TESTS ./tail-n0f:/proc/13090/status: missing or 'different': skipping this test SKIP: tail-n0f ./big-4gb: This test is relatively expensive, so it is disabled by default. To run it anyway, rerun make check with the RUN_EXPENSIVE_TESTS environment variable set to yes. E.g., env RUN_EXPENSIVE_TESTS=yes make check SKIP: big-4gb PASS: proc-ksyms PASS: start-middle sleeping for 7 seconds... [1]- Terminated tail --follow=name a foo err 21 PASS: assert sleeping for 7 seconds... [1]- Terminated tail --follow=name a foo err 21 PASS: assert-2 == All 4 tests passed (2 tests were not run) == Making check in test make check-TESTS PASS: test-tests == All 1 tests passed == Making check in touch make check-TESTS PASS: relative 0a1 touch: setting times of `/': Permission denied FAIL: not-owner PASS: no-create-missing PASS: fail-diag PASS: dir-1 PASS: dangling-symlink sleeping for 2 seconds... sleeping for 2 seconds... PASS: empty-file PASS: fifo sleeping for 2 seconds... PASS: no-rights PASS: obsolescent == 1 of 10 tests failed Please report to bug-coreutils@gnu.org == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
On Tue, May 10, 2005, Matthias Kurz wrote: On Mon, May 09, 2005, Paul Eggert wrote: [...] But I still don't get why the change is needed. It sounds like you're assuming Solaris 11 getopt might get fixed? But even in that case, the current code will work, right, since it will use GNU getopt? So this is just an optimization for the hypothetical case if Solaris 11 getopt gets fixed? In that case perhaps we should wait for Solaris 11 and test it before installing this patch, as it's more likely to cause a bug than to fix one. Well, it might still fail on other OSes, that also do not use GNU getopt. They do probably also not have the getopt_clip. I'll check this on IRIX, today. The vanilla cvs-1.12.12 builds on irix and seems to run. The included GNU getopt is used. There is a getopt.h, but no getopt_long_only. Thought, Derek's test for -+ would be necessary, but that's not the case. I do not have autoconf and automake, there, so i cannot test the various patches. I'm running out of time. I have to quit. Thanks very much for your effords. When there is something to test, i'll still try to help. (mk) -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 Im prämotorischen Cortex kann jeder ein Held sein. (bdw) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] [bug-gnulib] fts portability fix for hosts with unusual pointer semantics
James Youngman wrote:
Paul +static int
Paul +fts_compar (void const *a, void const *b)
Paul +{
Paul/* ... */
Paul + return pa[0]-fts_fts-fts_compar (pa, pb);
Paul +}
... compilers are likely to be able to inline the actual
subroutine call away in any case.
How should this be possible? The common C compilers are ahead-of-time
compilers, and neither the call from qsort to fts_compar nor the call
from fts_compar to the user-provided function can be inlined.
Bruno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Make Check on coreutils, darwin failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Adam Price on 5/9/2005 11:39 PM: Making check in touch make check-TESTS PASS: relative 0a1 touch: setting times of `/': Permission denied FAIL: not-owner I've noticed that cygwin also tends to fail this test, because the typical cygwin user installed / themselves (as c:\cygwin) and has write access to change /. I don't know if there is a better approach to finding a directory that the user does not have rights to (cygwin will soon have // appear as a directory with read-only properties, so // might work, but doesn't generalize well). Perhaps something like this is needed in tests/touch/not-owner: if test `stat -c %u /` = `id -u` ; then echo Skipping because / is owned by user 2 (exit 77); exit 77 fi group=`stat -c %g /` for g in `id -G` ; do if test $group = $g ; then echo Skipping because / belongs to user's group 2 (exit 77); exit 77 fi done - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgKqD84KuGfSFAYARAuuXAJ0Vo+uBwLnjzUXkK6YGeXN4kef1SwCgipI5 FwdGOXEIQ1a+eZ2lKf5KLuI= =ZqOw -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Make Check on coreutils, darwin failed
Eric Blake [EMAIL PROTECTED] wrote: According to Adam Price on 5/9/2005 11:39 PM: Making check in touch make check-TESTS PASS: relative 0a1 touch: setting times of `/': Permission denied FAIL: not-owner I've noticed that cygwin also tends to fail this test, because the typical cygwin user installed / themselves (as c:\cygwin) and has write access to change /. I don't know if there is a better approach to finding a directory that the user does not have rights to (cygwin will soon have // appear as a directory with read-only properties, so // might work, but doesn't generalize well). Perhaps something like this is needed in tests/touch/not-owner: if test `stat -c %u /` = `id -u` ; then ... Thanks to both of you. I've just added tests to check owner/group and whether / is writable -- using `test' makes it easier :) Index: tests/touch/not-owner === RCS file: /fetish/cu/tests/touch/not-owner,v retrieving revision 1.3 retrieving revision 1.5 diff -u -p -r1.3 -r1.5 --- tests/touch/not-owner 23 Jun 2004 15:07:05 - 1.3 +++ tests/touch/not-owner 10 May 2005 13:30:39 - 1.5 @@ -11,6 +11,17 @@ fi . $srcdir/../lang-default PRIV_CHECK_ARG=require-non-root . $srcdir/../priv-check +test=../../src/test +if $test -w /; then + echo Skipping because you have write access to /. + (exit 77); exit 77 +fi + +if $test -O / || $test -G /; then + echo Skipping because you own /. + (exit 77); exit 77 +fi + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
Paul Eggert wrote: Derek Price [EMAIL PROTECTED] writes: + myargv[[0]] = conftest; + myargv[[1]] = -+; This doesn't null-terminate myargv. But I still don't get why the change is needed. It sounds like you're assuming Solaris 11 getopt might get fixed? Yes, I suppose so, or a later patch release of Solaris 10. Or some other system that decides to ship a getopt.h with a getopt_long(), getopt_clip(), and a GNU compatible getopt(), however unlikely that may sound now. But even in that case, the current code will work, right, since it will use GNU getopt? So this is just an optimization for the hypothetical case if Solaris 11 getopt gets fixed? Basically. I was feeling guilty about not detecting the bug, but detecting a feature of the system and assuming the bug. This goes against the whole Autoconf test design philosophy, I thought. It's almost as bad as using `uname -a |sed' to detect the version number and using that to decide against the system getopt(), really. The new test detects the actual bug. In that case perhaps we should wait for Solaris 11 and test it before installing this patch, as it's more likely to cause a bug than to fix one. What sort of bug are you worried about? Regards, Derek ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
Paul Eggert wrote: Derek Price [EMAIL PROTECTED] writes: + myargv[[0]] = conftest; + myargv[[1]] = -+; This doesn't null-terminate myargv. Okay, looking at that in C89 now, but just out of curiosity, if argv needs to be NULL terminated, what's the point of argc? Revised patch attached. I restored a comment I probably shouldn't have cut as well. 2005-05-10 Derek Price [EMAIL PROTECTED] * m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible. Regards, Derek Index: m4/getopt.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v retrieving revision 1.9 diff -u -p -r1.9 getopt.m4 --- m4/getopt.m46 May 2005 01:04:20 - 1.9 +++ m4/getopt.m410 May 2005 13:56:05 - @@ -39,8 +39,26 @@ AC_DEFUN([gl_GETOPT], dnl Solaris 10 getopt doesn't handle `+' as a leading character in an dnl option string (as of 2005-05-05). if test -z $GETOPT_H; then - AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [], - [#include getopt.h]) + AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt, + [AC_RUN_IFELSE( +[AC_LANG_PROGRAM([#include getopt.h],[ + char *myargv[[3]]; + myargv[[0]] = conftest; + myargv[[1]] = -+; + myargv[[2]] = NULL; + return '?' != getopt (2, myargv, +a); +])], +gl_cv_func_gnu_getopt=yes, +gl_cv_func_gnu_getopt=no, +[dnl cross compiling - pessimistically guess based on decls + dnl Solaris 10 getopt doesn't handle `+' as a leading character in an + dnl option string (as of 2005-05-05). + AC_CHECK_DECL([getopt_clip], + [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes], +[#include getopt.h])])]) + if test $gl_cv_func_gnu_getopt = no; then + GETOPT_H=getopt.h + fi fi if test -n $GETOPT_H; then ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Kurz wrote: I'm running out of time. I have to quit. Thanks very much for your effords. When there is something to test, i'll still try to help. No problem. Thanks for your help, Matthias. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgL7qLD1OTBfyMaQRAgNTAJ4yFV0txiOeuKI9/459BArLy7iVSACfYZhj oP6Fu8IWbqICpJRFhSP376o= =LDtS -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
Derek Price writes: Okay, looking at that in C89 now, but just out of curiosity, if argv needs to be NULL terminated, what's the point of argc? I believe it was added for convenience back in the dark ages. All the Unix exec functions require a null-terminated argument list (and don't have an explicit argument count), so argv has naturally always been null terminated. (And the C Standard codified that behavior: at program startup, argv[argc] is required to be null.) -Larry Jones I don't think that question was very hypothetical at all. -- Calvin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
Derek Price [EMAIL PROTECTED] writes: Revised patch attached. Thanks; I installed the following slightly-different patch. 2005-05-10 Derek Price [EMAIL PROTECTED] * getopt.m4 (gl_GETOPT): Check for Solaris 10 bug, not decl, when possible. --- getopt.m4 6 May 2005 01:04:20 - 1.9 +++ getopt.m4 10 May 2005 19:11:00 - 1.10 @@ -1,4 +1,4 @@ -# getopt.m4 serial 8 +# getopt.m4 serial 9 dnl Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -39,8 +39,27 @@ AC_DEFUN([gl_GETOPT], dnl Solaris 10 getopt doesn't handle `+' as a leading character in an dnl option string (as of 2005-05-05). if test -z $GETOPT_H; then - AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [], - [#include getopt.h]) + AC_CACHE_CHECK([for working GNU getopt function], [gl_cv_func_gnu_getopt], + [AC_RUN_IFELSE( +[AC_LANG_PROGRAM([#include getopt.h], + [[ +char *myargv[3]; +myargv[0] = conftest; +myargv[1] = -+; +myargv[2] = 0; +return getopt (2, myargv, +a) != '?'; + ]])], +[gl_cv_func_gnu_getopt=yes], +[gl_cv_func_gnu_getopt=no], +[dnl cross compiling - pessimistically guess based on decls + dnl Solaris 10 getopt doesn't handle `+' as a leading character in an + dnl option string (as of 2005-05-05). + AC_CHECK_DECL([getopt_clip], + [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes], + [#include getopt.h])])]) + if test $gl_cv_func_gnu_getopt = no; then + GETOPT_H=getopt.h + fi fi if test -n $GETOPT_H; then ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
GNU getopt tries to do too much when it reorders the commandline and therefor needs the + as a workaround. I don't suppose it matters at this point, but I fail to see the connection here. You can tell GNU getopt to REQUIRE_ORDER instead of PERMUTE without using +, either directly or setting POSIXLY_CORRECT in various ways. See the __ordering enum in getopt_int.h, for example. (Seems like you probably already know this, so maybe it's unsuitable somehow, if so, sorry for the noise.) Also, I don't agree that it is doing too much to have PERMUTE be the default for GNU. It is very useful for most programs. cvs has exceptional command-line parsing needs. Happy hacking, karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
Paul Eggert wrote: Derek Price [EMAIL PROTECTED] writes: Revised patch attached. Thanks; I installed the following slightly-different patch. Works for me. Thanks Paul. Derek ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
install command
Hi, I am trying to use the install command for OpenNMS. The instructions say use the two options: -i and -u, but they are not available in with this command. The command is showed like this: install -disU. For some reason I have not be able to get any results, so I am helping you can help with this. Eddie ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date not parsing full iso-8601
As I read the documentation for gnu date it should parse iso-8601 dates correctly: File: coreutils.info, Node: General date syntax . . . The output of `date' is not always acceptable as a date string, not only because of the language problem, but also because there is no standard meaning for time zone items like `IST'. When using `date' to generate a date string intended to be parsed later, specify a date format that is independent of language and that does not use time zone items other than `UTC' and `Z'. Here are some ways to do this: $ LC_ALL=C TZ=UTC0 date Fri Dec 15 19:48:05 UTC 2000 $ TZ=UTC0 date +%Y-%m-%d %H:%M:%SZ 2000-12-15 19:48:05Z $ date --iso-8601=seconds # a GNU extension 2000-12-15T11:48:05-0800 $ date --rfc-2822 # a GNU extension Fri, 15 Dec 2000 11:48:05 -0800 $ date +%Y-%m-%d %H:%M:%S %z # %z is a GNU extension. 2000-12-15 11:48:05 -0800 But it doesn't appear that date does parse an iso-8601 date: $ date --date 2004-12-18T17:28:00+ date: invalid date `2004-12-18T17:28:00+' This also fails: $ date --date `date --iso-8601=seconds` Curiously it seems to be the timezone that it doing it because this DOES work: $ date --date 2004-12-18T17:28:00 Have I just misunderstood GNU date or have I really found a bug? Nic Ferrier ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Filename Globbing issues on Win32?
The MS-Windows way of globbing is described at MSDN: http://msdn.microsoft.com/library/en-us/vclang/html/_pluslang_Parsing_C.2b2b_.Command.2d.Line_Arguments.asp From this description it seems that your example should work; also native commands, such as dir, do expand the * when inside quotes. So possibly this behaviour of cp and other coreutils programs, is a bug, either in the Gnuwin32 port or in some system library, such as msvcrt.dll. Other MS-Windows ports, such as Cygwin, Djgpp and Unixutils, have the same behaviour, so I suspect it is a bug of some system library. Kees Zeelenberg From: Adin Burroughs Subject: Re: Filename Globbing issues on Win32? Date: Mon, 9 May 2005 12:59:32 -0600 I'm actually using the coreutils compiled and bundled with the GnuWin32 and UnxUtils projects. Both projects still refer back to the original Gnu coreutils lists. I may crosspost this thread over to those guys if I'm not totally crazy on this. :) And moving the asterisk outside the quotes didn't work: (ok, actual examples from the commandline this time) quote C:\Documents and Settings\Adncp c:\Program Files\Sony Handheld\adn\sunrise\s lot0\* k:\palm\PROGRAMS\plucker cp: missing destination file operand after `c:\\Program Files\\Sony Handheld\\ad n\\sunrise\\slot0* k:\\palm\\PROGRAMS\\plucker' Try `cp --help' for more information. C:\Documents and Settings\Adncp c:\Program Files\Sony Handheld\adn\sunrise\s lot0\* k:\palm\PROGRAMS\plucker cp: cannot stat `c:\\Program Files\\Sony Handheld\\adn\\sunrise\\slot0\\*': Inv alid argument C:\Documents and Settings\Adncp --version cp (GNU coreutils) 5.3.0 Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /endquote -adin On 5/9/05, Philip Rowlands [EMAIL PROTECTED] wrote: On Mon, 9 May 2005, Adin Burroughs wrote: OK, first off, I'm on Win32 (XP) using 5.3 of coreutils. I have been knocking my head on this and I'm feeling *really* stupid. I swear, I'm unix literate, but I can't seem to get the following to work without cheating: cp -uvp c:\dir with space\long path\* k:\path -- First, Do No Harm. Second, Do Good. --unknown ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Berry wrote: GNU getopt tries to do too much when it reorders the commandline and therefor needs the + as a workaround. I don't suppose it matters at this point, but I fail to see the connection here. You can tell GNU getopt to REQUIRE_ORDER instead of PERMUTE without using +, either directly or setting POSIXLY_CORRECT in various ways. I'd rather not control a function I'm calling by messing with environment variables, especially those that may have other side effects. See the __ordering enum in getopt_int.h, for example. (Seems like you probably already know this, so maybe it's unsuitable somehow, if so, sorry for the noise.) It doesn't look to me like there is an easy way to set this from a caller of getopt(). Also, I don't agree that it is doing too much to have PERMUTE be the default for GNU. It is very useful for most programs. cvs has exceptional command-line parsing needs. True. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgV4aLD1OTBfyMaQRAtYPAJ9q5KLtCt4T7JwYHNWSLqgPMKe2sgCg4D9I OIkpN56K4vKZXgSvo0tFmJM= =iNeT -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: install command
Chikaod Anyikire wrote: I am trying to use the install command for OpenNMS. The instructions say use the two options: -i and -u, but they are not available in with this command. The command is showed like this: install -disU. For some reason I have not be able to get any results, so I am helping you can help with this. Unfortunately there is very little information there to be able to help you. GNU install does not support all of those options. I checked the BSD man page for install too and neither does it support -U or -i. Who is to say what the author of whatever it is you are trying to do was intending? You mentioned -u but then showed -U. Generally upper and lower case are different options and the difference is significant. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
