bug#34700: rm refuses to remove files owned by the user, even in force mode
Le 2019-03-03 16:48, L A Walsh a écrit : On 3/3/2019 4:43 AM, Erik Auerswald wrote: Hi, On 3/3/19 09:40, L A Walsh wrote: On 3/2/2019 11:31 AM, Bob Proulx wrote: But regardless of that it does not change the fact that the entire purpose of read-only directories is to prevent removing and renaming of files within them. But not by the user owning them. The rationale given by the Go developers is to prevent downloaded test code to remove or alter files in the modules directory, not to prevent the user from doing that. I'm not familiar w/go, or why the user wants to purge something that sounded equivalent to a web-cache, vs. the local extension-source storage. The user (me) just wants to clean up files in his own home directory without special complications. The Go developers implemented "go clean -modcache" for that purpose. https://github.com/golang/go/issues/27161#issuecomment-415213240 https://tip.golang.org/cmd/go/#hdr-Remove_object_files_and_cached_files And having files that need special commands to be modified is quite umconfortable Not to mention the command may have been uninstalled leaving files on disk, is quite new, buggy, and full of unnexpected side effects (because it would have been too much to ask for a command that "just" cleans up the cache). If there is a utilities for what the user needs, why are they wanting 'rm' to do it? Is it just that they don't know about the util, or maybe the util has constraints on its use to delete the source if the cached version is deleted? I don't know. I do know that Google isn't known for following common sense standards and like to force its own way on people, so I don't know why the util isn't "working" for the original poster. It isn't "working". Besides the ro mode is not supposed to protect the files from users, it's supposed to protect the cache files from go unit tests, because google has moved go resources from plain directories to zip files, and code that attempts to manipulate zip files as if they were directories fails badly As one of the Go devs commented in one of the tickets after arguing for the ro change "I'm surprised rm is not smart enough to do the right thing" (meaning remove everything when asked without requiring a permission change, since the user owns everything) Regards, -- Nicolas Mailhot
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
On 03/03/19 16:59, Pádraig Brady wrote:
> A summary of the all signal options in my local set now is:
>
> --block-signal[=SIG]block delivery of SIG signal(s) to COMMAND
> --unblock-signal[=SIG] unblock delivery of SIG signal(s) to COMMAND
> --default-signal[=SIG] reset handling of SIG signal(s) to the default
> --ignore-signal[=SIG] set handling of SIG signals(s) to do nothing
> --list-signal-handling list non default signal handling to stderr
I think we might be also able to remove --unblock-signal,
and just have --default-signal.
I.E. I don't think one would want to set default signal handling,
but leave a signal blocked? Also I don't think one would
want to unblock a signal, but leave it ignored?
At least not and the level of env just exec()ing a program.
Anyway if those weird cases are needed, they can be achieved
by combining the options.
The attached does that, leaving us with:
--block-signal[=SIG]block delivery of SIG signal(s) to COMMAND
--default-signal[=SIG] reset handling of SIG signal(s) to the default
--ignore-signal[=SIG] set handling of SIG signals(s) to do nothing
--list-signal-handling list non default signal handling to stderr
cheers,
Pádraig.
From 7183477b7a5d9531a43b48beee8906ea7ae6fc06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 3 Mar 2019 17:40:34 -0800
Subject: [PATCH] env: have --default-signal imply --unblock-signal
Remove --unblock as i's not needed in isolation
---
doc/coreutils.texi | 12 +---
src/env.c | 9 +
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 0e4ed16..8112034 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -17247,10 +17247,11 @@ env --chdir=/build FOO=bar timeout 5 true
@end example
@item --default-signal[=@var{sig}]
-Reset signal @var{sig} to its default signal handler. Without @var{sig} all
-known signals are reset to their defaults. Multiple signals can be
-comma-separated. The following command runs @command{seq} with SIGINT and
-SIGPIPE set to their default (which is to terminate the program):
+Unblock and reset signal @var{sig} to its default signal handler.
+Without @var{sig} all known signals are reset to their defaults.
+Multiple signals can be comma-separated. The following command runs
+@command{seq} with SIGINT and SIGPIPE set to their default
+(which is to terminate the program):
@example
env --default-signal=PIPE,INT seq 1000 | head -n1
@@ -17302,9 +17303,6 @@ env --default-signal=INT,PIPE --ignore-signal=INT
@item --block-signal[=@var{sig}]
Block signal(s) @var{sig} from being delivered.
-@item --unblock-signal[=@var{sig}]
-Unblock signal(s) @var{sig}.
-
@item --list-blocked-signals
List blocked (masked) signals and exit.
If no signals are blocked, nothing is printed.
diff --git a/src/env.c b/src/env.c
index 9a910da..aa0cfbc 100644
--- a/src/env.c
+++ b/src/env.c
@@ -82,7 +82,6 @@ enum
DEFAULT_SIGNAL_OPTION = CHAR_MAX + 1,
IGNORE_SIGNAL_OPTION,
BLOCK_SIGNAL_OPTION,
- UNBLOCK_SIGNAL_OPTION,
LIST_SIGNAL_HANDLING_OPTION,
};
@@ -95,7 +94,6 @@ static struct option const longopts[] =
{"default-signal", optional_argument, NULL, DEFAULT_SIGNAL_OPTION},
{"ignore-signal", optional_argument, NULL, IGNORE_SIGNAL_OPTION},
{"block-signal", optional_argument, NULL, BLOCK_SIGNAL_OPTION},
- {"unblock-signal", optional_argument, NULL, UNBLOCK_SIGNAL_OPTION},
{"list-signal-handling", no_argument, NULL, LIST_SIGNAL_HANDLING_OPTION},
{"debug", no_argument, NULL, 'v'},
{"split-string", required_argument, NULL, 'S'},
@@ -136,9 +134,6 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--block-signal[=SIG]block delivery of SIG signal(s) to COMMAND\n\
"), stdout);
fputs (_("\
- --unblock-signal[=SIG] unblock delivery of SIG signal(s) to COMMAND\n\
-"), stdout);
- fputs (_("\
--default-signal[=SIG] reset handling of SIG signal(s) to the default\n\
"), stdout);
fputs (_("\
@@ -823,6 +818,7 @@ main (int argc, char **argv)
break;
case DEFAULT_SIGNAL_OPTION:
parse_signal_action_params (optarg, true);
+ parse_block_signal_params (optarg, false);
break;
case IGNORE_SIGNAL_OPTION:
parse_signal_action_params (optarg, false);
@@ -830,9 +826,6 @@ main (int argc, char **argv)
case BLOCK_SIGNAL_OPTION:
parse_block_signal_params (optarg, true);
break;
-case UNBLOCK_SIGNAL_OPTION:
- parse_block_signal_params (optarg, false);
- break;
case LIST_SIGNAL_HANDLING_OPTION:
report_signal_handling = true;
break;
--
2.9.3
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
On 03/03/19 16:07, Pádraig Brady wrote:
> On 03/03/19 15:36, Pádraig Brady wrote:
>> On 25/02/19 22:35, Pádraig Brady wrote:
>>> Thanks for doing all that.
>>> I've attached a few changes:
>>>
>>> - spelling fixes
>>> - usage() clarified/reordered
>>> - ensure sigset_t are initialized
>>> - Don't setprocmask() unless specified
>>> - Simplified SETMASK_SIGNAL_OPTION handling
>>> - The test missed `env` as a prerequisite
>>> - The test was slow/spun cpu, so used sleep instead of seq
>>> - Used $SHELL in case sh didn't support trap
>>>
>>> I see that the last signal that `kill -l` lists is not included.
>>> I think we should be processing SIGNUM_BOUND also?
>>
>> An additional patch attached to replace --list-signal-actions
>> with --list-ignored-signals. This is simpler, and more symmetric
>> with the other options. Also the extra output was moot I think
>> since handlers are reset upon exec
>
> I've locally adjusted the NEWS/texi for that patch also.
> I've a local patch to include SIGNUM_BOUND which I won't spam the list with.
>
> Attached is a patch to remove the -p and --set-mask options,
> which I've a light preference for.
> I'll think some more about it.
Attached is a patch to combine the two --list options
to a single --list-signal-handling option.
This also doesn't exit, and so is more useful as
users can add --list-signal to their env commands
to diagnose signal handling. One can easily use `true`
as the command to get the original list only functionality.
A summary of the all signal options in my local set now is:
--block-signal[=SIG]block delivery of SIG signal(s) to COMMAND
--unblock-signal[=SIG] unblock delivery of SIG signal(s) to COMMAND
--default-signal[=SIG] reset handling of SIG signal(s) to the default
--ignore-signal[=SIG] set handling of SIG signals(s) to do nothing
--list-signal-handling list non default signal handling to stderr
cheers,
Pádraig
From 715254df092d6e3dfac7bdfd72f7307dce21dabd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 3 Mar 2019 16:50:27 -0800
Subject: [PATCH] env: add only a single --list-signal-handling option
This also doesn't exit, which is more useful as
it directly confirms any inherited handling
in combination with any signal settings we may have set.
One can easily use `true` as the command to get
the original list only functionality
---
NEWS | 3 ++-
doc/coreutils.texi | 5 ++---
src/env.c | 54 +++---
3 files changed, 23 insertions(+), 39 deletions(-)
diff --git a/NEWS b/NEWS
index 33f1ef2..6fbc8f1 100644
--- a/NEWS
+++ b/NEWS
@@ -90,7 +90,8 @@ GNU coreutils NEWS-*- outline -*-
env now supports '--{block,unblock,setmask}-signal[=SIG]' to block/unblock
signal delivery before executing a program.
- env now supports '--list-blocked-signals', and '--list-ignored-signals'.
+ env now supports '--list-signal-handling' to identify signal handling
+ before executing a program.
** New commands
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3c220ea..0e4ed16 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -17309,9 +17309,8 @@ Unblock signal(s) @var{sig}.
List blocked (masked) signals and exit.
If no signals are blocked, nothing is printed.
-@item --list-ignored-signals
-List ignored signals and exit.
-If no signals are ignored, nothing is printed.
+@item --list-signal-handling
+List blocked or ignored signals to stderr, before executing a command.
@item -v
@itemx --debug
diff --git a/src/env.c b/src/env.c
index 7bc3c7b..9a910da 100644
--- a/src/env.c
+++ b/src/env.c
@@ -70,6 +70,9 @@ static sigset_t unblock_signals;
/* Whether signal mask adjustment requested. */
static bool sig_mask_changed;
+/* Whether to list non default handling. */
+static bool report_signal_handling;
+
static char const shortopts[] = "+C:ipS:u:v0 \t";
/* For long options that have no equivalent short option, use a
@@ -80,8 +83,7 @@ enum
IGNORE_SIGNAL_OPTION,
BLOCK_SIGNAL_OPTION,
UNBLOCK_SIGNAL_OPTION,
- LIST_BLOCKED_SIGNALS_OPTION,
- LIST_IGNORED_SIGNALS_OPTION,
+ LIST_SIGNAL_HANDLING_OPTION,
};
static struct option const longopts[] =
@@ -94,8 +96,7 @@ static struct option const longopts[] =
{"ignore-signal", optional_argument, NULL, IGNORE_SIGNAL_OPTION},
{"block-signal", optional_argument, NULL, BLOCK_SIGNAL_OPTION},
{"unblock-signal", optional_argument, NULL, UNBLOCK_SIGNAL_OPTION},
- {"list-blocked-signals", no_argument, NULL, LIST_BLOCKED_SIGNALS_OPTION},
- {"list-ignored-signals", no_argument, NULL, LIST_IGNORED_SIGNALS_OPTION},
+ {"list-signal-handling", no_argument, NULL, LIST_SIGNAL_HANDLING_OPTION},
{"debug", no_argument, NULL, 'v'},
{"split-string", required_argument, NULL, 'S'},
{GETOPT_HELP_OPTION_DECL},
@@ -144,10 +145,7 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--ignore-signal[=SIG] set
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
On 03/03/19 15:36, Pádraig Brady wrote:
> On 25/02/19 22:35, Pádraig Brady wrote:
>> Thanks for doing all that.
>> I've attached a few changes:
>>
>> - spelling fixes
>> - usage() clarified/reordered
>> - ensure sigset_t are initialized
>> - Don't setprocmask() unless specified
>> - Simplified SETMASK_SIGNAL_OPTION handling
>> - The test missed `env` as a prerequisite
>> - The test was slow/spun cpu, so used sleep instead of seq
>> - Used $SHELL in case sh didn't support trap
>>
>> I see that the last signal that `kill -l` lists is not included.
>> I think we should be processing SIGNUM_BOUND also?
>
> An additional patch attached to replace --list-signal-actions
> with --list-ignored-signals. This is simpler, and more symmetric
> with the other options. Also the extra output was moot I think
> since handlers are reset upon exec
I've locally adjusted the NEWS/texi for that patch also.
I've a local patch to include SIGNUM_BOUND which I won't spam the list with.
Attached is a patch to remove the -p and --set-mask options,
which I've a light preference for.
I'll think some more about it.
cheers,
Pádraig
>From ae8d2ab5d9a380051a1ae1d315832e98f40ff456 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 3 Mar 2019 16:02:55 -0800
Subject: [PATCH] env: remove shortcut signal handling options
* src/env.c: Remove -p and --setmask-signal
---
doc/coreutils.texi | 9 -
src/env.c| 16
tests/misc/env-signal-handler.sh | 10 --
3 files changed, 35 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 4dea101..3c220ea 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -17305,10 +17305,6 @@ Block signal(s) @var{sig} from being delivered.
@item --unblock-signal[=@var{sig}]
Unblock signal(s) @var{sig}.
-@item --setmask-signal[=@var{sig}]
-Set list of blocked signals to @var{sig}. All other signals will be unblocked.
-
-
@item --list-blocked-signals
List blocked (masked) signals and exit.
If no signals are blocked, nothing is printed.
@@ -17317,11 +17313,6 @@ If no signals are blocked, nothing is printed.
List ignored signals and exit.
If no signals are ignored, nothing is printed.
-
-@item -p
-Equivalent to @option{--default-signal=PIPE} - sets SIGPIPE to its default
-behavior (terminate a program upon @samp{SIGPIPE}).
-
@item -v
@itemx --debug
@opindex -v
diff --git a/src/env.c b/src/env.c
index 90821c3..7bc3c7b 100644
--- a/src/env.c
+++ b/src/env.c
@@ -80,7 +80,6 @@ enum
IGNORE_SIGNAL_OPTION,
BLOCK_SIGNAL_OPTION,
UNBLOCK_SIGNAL_OPTION,
- SETMASK_SIGNAL_OPTION,
LIST_BLOCKED_SIGNALS_OPTION,
LIST_IGNORED_SIGNALS_OPTION,
};
@@ -95,7 +94,6 @@ static struct option const longopts[] =
{"ignore-signal", optional_argument, NULL, IGNORE_SIGNAL_OPTION},
{"block-signal", optional_argument, NULL, BLOCK_SIGNAL_OPTION},
{"unblock-signal", optional_argument, NULL, UNBLOCK_SIGNAL_OPTION},
- {"setmask-signal", optional_argument, NULL, SETMASK_SIGNAL_OPTION},
{"list-blocked-signals", no_argument, NULL, LIST_BLOCKED_SIGNALS_OPTION},
{"list-ignored-signals", no_argument, NULL, LIST_IGNORED_SIGNALS_OPTION},
{"debug", no_argument, NULL, 'v'},
@@ -140,9 +138,6 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--unblock-signal[=SIG] unblock delivery of SIG signal(s) to COMMAND\n\
"), stdout);
fputs (_("\
- --setmask-signal[=SIG] set full mask with SIG signal(s) blocked\n\
-"), stdout);
- fputs (_("\
--default-signal[=SIG] reset handling of SIG signal(s) to the default\n\
"), stdout);
fputs (_("\
@@ -155,9 +150,6 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--list-blocked-signals list blocked (masked) signals and exit\n\
"), stdout);
fputs (_("\
- -p same as --default-signal=PIPE\n\
-"), stdout);
- fputs (_("\
-v, --debug print verbose information for each processing step\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
@@ -845,10 +837,6 @@ main (int argc, char **argv)
case '0':
opt_nul_terminate_output = true;
break;
-case 'p':
- /* alias to --default-signal=PIPE */
- signals[SIGPIPE] = DEFAULT;
- break;
case DEFAULT_SIGNAL_OPTION:
parse_signal_action_params (optarg, true);
break;
@@ -861,10 +849,6 @@ main (int argc, char **argv)
case UNBLOCK_SIGNAL_OPTION:
parse_block_signal_params (optarg, false);
break;
-case SETMASK_SIGNAL_OPTION:
- parse_block_signal_params (NULL, false);
- parse_block_signal_params (optarg, true);
- break;
case LIST_BLOCKED_SIGNALS_OPTION:
list_blocked_signals ();
break;
diff --git a/tests/misc/env-signal-handler.sh b/tests/misc/env-signal-handler.sh
index 4dd90c2..5e6b57e 100755
---
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
On 25/02/19 22:35, Pádraig Brady wrote:
> Thanks for doing all that.
> I've attached a few changes:
>
> - spelling fixes
> - usage() clarified/reordered
> - ensure sigset_t are initialized
> - Don't setprocmask() unless specified
> - Simplified SETMASK_SIGNAL_OPTION handling
> - The test missed `env` as a prerequisite
> - The test was slow/spun cpu, so used sleep instead of seq
> - Used $SHELL in case sh didn't support trap
>
> I see that the last signal that `kill -l` lists is not included.
> I think we should be processing SIGNUM_BOUND also?
An additional patch attached to replace --list-signal-actions
with --list-ignored-signals. This is simpler, and more symmetric
with the other options. Also the extra output was moot I think
since handlers are reset upon exec. For completeness the transitions are:
upon fork
default -> default
handled -> handled
ignored -> ignored
pending -> cleared
blocked -> blocked
upon exec
default -> default
handled -> default
ignored -> ignored
pending -> pending
blocked -> blocked
shell has additional rules:
can't unignore
handled -> default in subshell
I'll squash this into yours, before commit.
cheers,
Pádraig
>From a8e531b15a2e85ecf7d18526bfbb7990537621b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 3 Mar 2019 15:29:59 -0800
Subject: [PATCH] env: use --list-ignored-signals instead of
--list-signals-action
This is more symmetric and anyway signal handlers are
reset upon exec(), so the more complicated reporting is moot.
---
src/env.c | 60 ++--
1 file changed, 26 insertions(+), 34 deletions(-)
diff --git a/src/env.c b/src/env.c
index 1acfc11..74043b1 100644
--- a/src/env.c
+++ b/src/env.c
@@ -81,8 +81,8 @@ enum
BLOCK_SIGNAL_OPTION,
UNBLOCK_SIGNAL_OPTION,
SETMASK_SIGNAL_OPTION,
- LIST_SIGNAL_ACTIONS_OPTION,
LIST_BLOCKED_SIGNALS_OPTION,
+ LIST_IGNORED_SIGNALS_OPTION,
};
static struct option const longopts[] =
@@ -93,11 +93,11 @@ static struct option const longopts[] =
{"chdir", required_argument, NULL, 'C'},
{"default-signal", optional_argument, NULL, DEFAULT_SIGNAL_OPTION},
{"ignore-signal", optional_argument, NULL, IGNORE_SIGNAL_OPTION},
- {"list-signal-actions", no_argument, NULL, LIST_SIGNAL_ACTIONS_OPTION},
{"block-signal", optional_argument, NULL, BLOCK_SIGNAL_OPTION},
{"unblock-signal", optional_argument, NULL, UNBLOCK_SIGNAL_OPTION},
{"setmask-signal", optional_argument, NULL, SETMASK_SIGNAL_OPTION},
{"list-blocked-signals", no_argument, NULL, LIST_BLOCKED_SIGNALS_OPTION},
+ {"list-ignored-signals", no_argument, NULL, LIST_IGNORED_SIGNALS_OPTION},
{"debug", no_argument, NULL, 'v'},
{"split-string", required_argument, NULL, 'S'},
{GETOPT_HELP_OPTION_DECL},
@@ -149,7 +149,7 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--ignore-signal[=SIG] set handling of SIG signals(s) to do nothing\n\
"), stdout);
fputs (_("\
- --list-signal-actions list signals with non-default actions and exit\n\
+ --list-ignored-signals list ignored signals and exit\n\
"), stdout);
fputs (_("\
--list-blocked-signals list blocked (masked) signals and exit\n\
@@ -680,34 +680,6 @@ reset_signal_handlers (void)
}
}
-static void
-list_signal_actions (void)
-{
- char signame[SIG2STR_MAX];
- const char* action;
-
- for (int i = 1; i < SIGNUM_BOUND; i++)
-{
- struct sigaction act;
- if (sigaction (i, NULL, ))
-continue;
-
- if (act.sa_flags & SA_SIGINFO)
-action = "sig-action";
- else if (act.sa_handler == SIG_DFL)
-continue; /* no need to print defaults. */
- else if (act.sa_handler == SIG_IGN)
-action = "ignore";
- else
-action = "sig-handler";
-
- sig2str (i, signame);
- printf ("%-10s (%2d): %s\n", signame, i, action);
-}
-
- exit (EXIT_SUCCESS);
-}
-
static void
parse_block_signal_params (const char* optarg, bool block)
@@ -819,6 +791,26 @@ list_blocked_signals (void)
exit (EXIT_SUCCESS);
}
+static void
+list_ignored_signals (void)
+{
+ char signame[SIG2STR_MAX];
+
+ for (int i = 1; i < SIGNUM_BOUND; i++)
+{
+ struct sigaction act;
+ if (sigaction (i, NULL, ))
+continue;
+
+ if (act.sa_handler != SIG_IGN)
+continue;
+
+ sig2str (i, signame);
+ printf ("%-10s (%2d)\n", signame, i);
+}
+
+ exit (EXIT_SUCCESS);
+}
int
main (int argc, char **argv)
@@ -863,9 +855,6 @@ main (int argc, char **argv)
case IGNORE_SIGNAL_OPTION:
parse_signal_action_params (optarg, false);
break;
-case LIST_SIGNAL_ACTIONS_OPTION:
- list_signal_actions ();
- break;
case BLOCK_SIGNAL_OPTION:
parse_block_signal_params (optarg, true);
break;
@@ -879,6 +868,9 @@ main (int argc, char **argv)
case LIST_BLOCKED_SIGNALS_OPTION:
bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS
On 26/07/18 18:23, Paul Eggert wrote:
> Pádraig Brady wrote:
>> I've pushed the c_iscntrl patch since it's simplest
>> and probably most appropriate patch for an existing release.
>
> Yes, that makes sense for a quick patch. However, for the next release I
> think
> it'd be better to catch encoding errors and multibyte control characters,
> given
> the problems noted. I installed the attached further patch to try to do this.
> This fixes the problem that Bruno noted, along with two others; my earlier
> patch
> neglected the possibility that mbrtowc can return 0, and it incorrectly
> assumed
> wide control characters always have a single-byte representation.
>
> Either way the original bug appears to be fix so I'm boldly closing the bug
> report.
Reviewing this, I dislike the way that we're now enforcing that
the file system locale needs to match the current user's locale
or otherwise df will not output all original characters.
That has the potential to break scripts, as mismatched
encodings is a common issue.
In the attached I've taken the original less aggressive replacement
policy when not outputting to a tty, leaving more sanitizing to the tty case.
cheers,
Pádraig
>From 97bc0e17065950f96a6e1350d1ed8db65ebfee96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 3 Mar 2019 14:35:18 -0800
Subject: [PATCH] df: don't require file system and display encodings to match
* src/df.c (replace_problematic_chars): A new wrapper to be
more conservative in our replacement when not connected to a tty.
* tests/df/problematic-chars.sh: Add a test case.
---
src/df.c | 34 +++---
tests/df/problematic-chars.sh | 29 +++--
2 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/src/df.c b/src/df.c
index 1eb7bcd..041f282 100644
--- a/src/df.c
+++ b/src/df.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -273,10 +274,26 @@ static struct option const long_options[] =
{NULL, 0, NULL, 0}
};
+/* Replace problematic chars with '?'.
+ Since only control characters are currently considered,
+ this should work in all encodings. */
+
+static void
+replace_control_chars (char *cell)
+{
+ char *p = cell;
+ while (*p)
+{
+ if (c_iscntrl (to_uchar (*p)))
+*p = '?';
+ p++;
+}
+}
+
/* Replace problematic chars with '?'. */
static void
-hide_problematic_chars (char *cell)
+replace_invalid_chars (char *cell)
{
char *srcend = cell + strlen (cell);
char *dst = cell;
@@ -310,6 +327,17 @@ hide_problematic_chars (char *cell)
*dst = '\0';
}
+static void
+replace_problematic_chars (char *cell)
+{
+ static int tty_out = -1;
+ if (tty_out < 0)
+tty_out = isatty (STDOUT_FILENO);
+
+ (tty_out ? replace_invalid_chars : replace_control_chars) (cell) ;
+}
+
+
/* Dynamically allocate a row of pointers in TABLE, which
can then be accessed with standard 2D array notation. */
@@ -591,7 +619,7 @@ get_header (void)
if (!cell)
xalloc_die ();
- hide_problematic_chars (cell);
+ replace_problematic_chars (cell);
table[nrows - 1][col] = cell;
@@ -1205,7 +1233,7 @@ get_dev (char const *disk, char const *mount_point, char const* file,
if (!cell)
assert (!"empty cell");
- hide_problematic_chars (cell);
+ replace_problematic_chars (cell);
size_t cell_width = mbswidth (cell, 0);
columns[col]->width = MAX (columns[col]->width, cell_width);
table[nrows - 1][col] = cell;
diff --git a/tests/df/problematic-chars.sh b/tests/df/problematic-chars.sh
index 34e743b..aa4c131 100755
--- a/tests/df/problematic-chars.sh
+++ b/tests/df/problematic-chars.sh
@@ -17,14 +17,17 @@
# along with this program. If not, see
bug#34700: rm refuses to remove files owned by the user, even in force mode
On 3/3/2019 4:43 AM, Erik Auerswald wrote: > Hi, > > On 3/3/19 09:40, L A Walsh wrote: > >> On 3/2/2019 11:31 AM, Bob Proulx wrote: >> >>> But regardless of that it does not change the fact that the entire >>> purpose of read-only directories is to prevent removing and renaming >>> of files within them. >>> >>> >> >> But not by the user owning them. >> > > The rationale given by the Go developers is to prevent downloaded test > code to remove or alter files in the modules directory, not to prevent > the user from doing that. > I'm not familiar w/go, or why the user wants to purge something that sounded equivalent to a web-cache, vs. the local extension-source storage. > The Go developers implemented "go clean -modcache" for that purpose. > https://github.com/golang/go/issues/27161#issuecomment-415213240 > https://tip.golang.org/cmd/go/#hdr-Remove_object_files_and_cached_files > If there is a utilities for what the user needs, why are they wanting 'rm' to do it? Is it just that they don't know about the util, or maybe the util has constraints on its use to delete the source if the cached version is deleted? I don't know. I do know that Google isn't known for following common sense standards and like to force its own way on people, so I don't know why the util isn't "working" for the original poster. > I concur to let software handle repetitive tasks. That's one of the reasons I got into computer SW development to begin with. I wanted to be able to program the computer to automatically do the things I'd normally have to do manually. > If cleaning the cache occurs all the time, using "go cache -modcache" > (or whatever program is appropriate for the specific cache) should be > the routine used. If there is no specialized program provided yet, a > script could be developed for that purpose. > Well, that's might be the rub -- the current cache-cleaning program may not be doing things "when" and "how" the user wants (I don't know). Even if there is a specialized program that provides one way to clean a cache, that doesn't mean it works for the original user. Another possibility is that they might want to delete only files meeting some specific criteria. If the provided tool doesn't do what they want or does "too much", they may want to have their own way of cleaning things up. I've had more than one process that existed and worked well for me before google got involved. My over-active imagination can easily come up with situations and possibilities where the user might prefer their own controls in place. Cheers, Linda
bug#34700: rm refuses to remove files owned by the user, even in force mode
Hi, On 3/3/19 09:40, L A Walsh wrote: On 3/2/2019 11:31 AM, Bob Proulx wrote: But regardless of that it does not change the fact that the entire purpose of read-only directories is to prevent removing and renaming of files within them. But not by the user owning them. The rationale given by the Go developers is to prevent downloaded test code to remove or alter files in the modules directory, not to prevent the user from doing that. [...] I would suggest people with specific directories that inhibit deletion of files inside although they should not (e.g. a "cache") to deliberatly change the permissions of said directories prior to deleting files inside. Using a script like the above, even without the basic mistakes in the script, is quite dangerous. Yeah...I wouldn't do it, I'd write a script that invokes the app and clears out the cache dir when the app exits if it bothered me enough. The Go developers implemented "go clean -modcache" for that purpose. https://github.com/golang/go/issues/27161#issuecomment-415213240 https://tip.golang.org/cmd/go/#hdr-Remove_object_files_and_cached_files Much better to let the computer do the repetitive deletions. If I do it manually, it increases the chances of me creating a problem the more often I do it. Really -- scripts are much better at handling redundant/routine matters that turn parts of my brain off. OTOH, some people are better at redundant detail and don't suffer the same problems I would. People are different. I concur to let software handle repetitive tasks. If cleaning the cache occurs seldom, manually performing the changes, or better invoking an existing specialized program (or script) for this specific cache seems to be better than circumventing the safety net in a general purpose utility. Especially if this circumvention means transparently changing access rights on a directory that is not mentioned in the utility invocation. If cleaning the cache occurs all the time, using "go cache -modcache" (or whatever program is appropriate for the specific cache) should be the routine used. If there is no specialized program provided yet, a script could be developed for that purpose. Thanks, Erik
bug#34700: rm refuses to remove files owned by the user, even in force mode
On 3/2/2019 11:31 AM, Bob Proulx wrote: > But regardless of that it does not change the fact that the entire > purpose of read-only directories is to prevent removing and renaming > of files within them. > But not by the user owning them. I don't remember the last time I used chmod -w to prevent myself from deleting all the files in a directory. I use it to prevent other people from removing/renaming. If I want to give myself "pause", I'll set them to immutable (on linux) and chmod read-only or system on windows -- both of those give some pause to the standard flow. But read-only and owned by me, takes about an extra 1-2 seconds as I tack sudo on the front and run right over user perms. > >> I would suggest people with specific directories that inhibit deletion of >> files inside although they should not (e.g. a "cache") to deliberatly change >> the permissions of said directories prior to deleting files inside. Using a >> script like the above, even without the basic mistakes in the script, is >> quite dangerous. >> Yeah...I wouldn't do it, I'd write a script that invokes the app and clears out the cache dir when the app exits if it bothered me enough. Much better to let the computer do the repetitive deletions. If I do it manually, it increases the chances of me creating a problem the more often I do it. Really -- scripts are much better at handling redundant/routine matters that turn parts of my brain off. OTOH, some people are better at redundant detail and don't suffer the same problems I would. People are different. >
