Bug#515862: The German version of Lenny release notes contrasts to the English version regarding case sensitive filename handling for vfat when the utf8 option is used
Package: release-notes The german translation of the release-notes states, that the Linux kernel does not support case-sensitive filename handling for vfat when the utf8 option is used (quoting http://www.debian.org/releases/lenny/i386/release-notes/ch-information.de.html#partitionenc): Zu beachten ist, dass der Linux-Kernel es nicht unterstützt, zwischen Groß- und Kleinschreibung in Dateinamen zu unterscheiden, wenn bei vfat die utf8-Option genutzt wird. In contrast to the german translation, according to the English Version, the kernel does not support case-insensitive filename handling for vfat when the utf8 option is used. Which statement is the correct one? If the English statement is the correct one, then one possible translation to the German version could be: Zu beachten ist, dass der Linux-Kernel es nicht unterstützt, Unterschiede in der Groß- und Kleinschreibung in Dateinamen zu ignorieren, wenn bei vfat die utf8-Option genutzt wird. Could someone correct this? Thank you in advance. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so: | my full name, like Helmut Waitzmann x...@example.net, (Helmut Waitzmann) x...@example.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#276419: [Pkg-shadow-devel] Bug#276419: su appends the positional args to the command line
invocation will remain the same with both old and new su. %% Emacs Local Variables: %% Emacs coding: iso-8859-1 %% Emacs fill-column: 75 %% Emacs End: Sure. But not during August while many DD's are VAC (and not only French ones). We should make the announcement ASAP. Idealistically before I leave for holidays on Aug 1st for something like 3 weeks. This announcement would mention September 15th as target release date for the change, leaving people enough time to preventively adapt their work. The announcement must be as short as possible and be very clear bout the consequence. Is the su adaption howto above too long? Is it clear enough? Deep technical details and rationale should be left to an appendix. Part of that appendix should be a RTFM to the manual page bash(1): namely the invocation options '-c' and '-s', and the section about parameter expansion. -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
' 'ls -- $@', because it concatenates all remaining parameters to the command string. Therefore, Debian's old su thwarts the second way to achieve proper parameter passing! That's one of the reasons why I want Debian's su behavior to change to Debian's old su's specification (i.e. manual page) and Linux Standard Base', Fedora's, HPUX's and Solaris' su's semantics and specification. Let me drop some words about (using Debian's old su) su username command A $B C $D and (using Debian's new su) su username -c command A \$B\ \C $D\ . As Debian's both old an new su don't do any quoting, there is no way to construct an invocation of su without using the positional parameters or explicit quoting (e.g. using printf ' %q') by simply inserting quotation marks into the command string: For example: $ A=\':; cd; rm -r .;'; cd; rm -r .;\:; cd; rm -r .;: With Debian's old su, all four commands $ su username ls \$A\ $ su username ls '$A' $ su username ls $A $ su username -c ls \[EMAIL PROTECTED] bash $A would empty username's home directory, whereas Debian's new su, Linux Standard Base's su, etc, when invoked by $ su username -c ls \[EMAIL PROTECTED] bash $A would do what it is told to do. Best regards, Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Bug#276419: su appends the positional args to the command line
Nicolas François [EMAIL PROTECTED] writes: a patch was included in the 4.0.3-36 release, but this one breaks some scripts (see #317264). which are broken and need to be fixed. See below. Thus, I'm considering to revert this patch and fix your bug by documenting the su behavior in its man page. Here are some details on the issues introduced by the patch: * arguments are no more concatenated to provide only one string to the -c option of the shell: if some arguments are provided after the command provided by -c, these arguments are provided to the shell that interprets the command, not to the command itself. For example: $ bash -c 'echo $@' a b c will print b c but: $ bash -c echo a b c will only display an empty line This behavior corresponds to the Debian manual page, the Linux Standard Base and concurres with the behavior of Fedora Linux' and HPUX's su (and if I remember correctly, solaris' su, too) and is correct behavior. Passing additional arguments to su and banking on concatenation to the command line is broken usage of su: Neither Debian's nor Fedora's nor HPUX's su's manual page nor the Linux Standard Base supports this. The rule is simple: If you want su to pass a command line with concatenated additional args, then simply concatenate them to the command line before passing it to su. * -c is no more provided to the shell when it is not provided to su: This break invocation of su like: $ su $LOGNAME bash /bin/bash: /bin/bash: cannot execute binary file The same is true here. Passing a command line to su without a preceding -c is broken usage of su: Neither Debian's nor Fedora's nor HPUX's su's manual page nor the Linux Standard Base supports this. The rule is simple: If you want su to provide a -c option to the shell, then simply provide it to su. As the old behaviors are assumed by some packages (at least pbuilder, and probably others), Those packages are broken and should be fixed: 1. If there is a command line to be passed, precede it with -c. 2. If there are additional arguments to be concatenated to the command line, concatenate them to the command line. Then those packages will work both with old and new su and there will be no need to revert the patch, and just document the fact that -c is always provided to the invoked shell (if there are additional arguments), and that the arguments are provided in a concatenated form to the -c flag. Do you agree with this? As it breaks the specifications of Linux Standard Base, I don't. Please, don't revert to a broken su. That would make Debian's su different from any other su in UNIX-like operating systems and restrict it to a very small subset of invocations it will serve. On the other hand, the invocation $ su - someone -c 'for arg; do process $arg; done' * , which meets the specifications, will fail with old su, as it will be treated like $ (set x * shift exec su - someone -c 'for arg; do process $arg; done '$* ) , which will not have the intended behavior as long as at least one additional argument is supplied. And there is no remedy, no matter how many levels of escape are applied. What do you think about creating a su-old-behavior package, which depends on su (and will work with both old and new su) and contains a wrapper executable (shell script, perl script or binary) called e.g. old-su, to provide the old behavior of su using new (or old) su? Then all fixing to be done to packages assuming the old behavior of su would be to substitute all calls to su with calls to old-su and making a dependency to the su-old-behavior package. Do you think it is worth while doing that? To fix your issues, there will still be the solutions of: * use su -- - $LOGNAME bash -x instead of su -- - $LOGNAME -x This is not a solution. Using new su: $ su -- - $LOGNAME -x will start a login shell in debug mode, whereas using old su $ su -- - $LOGNAME bash -x will start a login shell which will start a bash in debug mode. It will not help me debugging my login shell, especially when I want to pass positional arguments to an interactive login shell (to be used in $HOME/.profile). PS: I'm BCC'ing you to your address without nospam, sorry if you receive this mail twice) As long as [EMAIL PROTECTED] is included in the list of recipients or Helmut Waitzmann (Debian Bug Tracking System) [EMAIL PROTECTED] is included in the revealed list of recipients (i.e. BCC will not work), I'll receive that mail. Best regards, Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
Bug#317264: login: Current su breaks pbuilder
Junichi Uekawa [EMAIL PROTECTED] writes: Why is su changing behavior? Old su doesn't meet its specifications (i.e. manual page). Please see Bug#276419 for a detailed discussion. For example, according to the su manual page, $ su - userid -xs 'startup parameter' should start an interactive login shell with debug mode switched on and supply the additional positional argument startup parameter to it rather than starting an noninteractive login shell with the positional arguments -c -xs startup parameter, i.e. a commandline -xs startup parameter and no additional positional arguments. With (old) su, you cannot pass additional positional arguments and options (other than -c) to the shell. I have concerns wrt shell quoting, Could you please explain more detailed? Best regards, Helmut -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310511: 'tar --keep-newer-files' deletes old/extracts new files
) If '--keep-newer-files' is FOLLOWED by the additional option '--unlink-first', then the archive member is extracted (see line 98 to 101). The file is unlinked (the hardlink is broken), which is CORRECT. (5) The same error like in (1) arises, when option '--keep-newer-files' is PRECEDED by option '--unlink-first' (see lines 102 to 107): The old file is unlinked and no file is created. Second condition: The file in the file system is NEWER than the archive member to be extracted from the archive. So tar should not extract it. (6) Tar does not extract the archive member (lines 108 to 112): The file status change date, the link count, and the file size remain unchanged (compare with line 73), which is CORRECT. (7) If '--keep-newer-files' is FOLLOWED by '--overwrite', then the archive member is extracted (see lines 113 to 116): The file is overwritten rather than preserved. The link count remains 2, but the file size and the file status change date is changed, which is an ERROR. (8) If '--keep-newer-files' is PRECEDED by option '--overwrite' (lines 117 to 121), the file is preserved like in (6), which is CORRECT. (9) If '--keep-newer-files' is FOLLOWED by '--unlink-first', then the archive member is extracted (lines 122 to 125): The file is unlinked and created rather than preserved. The hardlink is broken, and the file size and the file status change date is changed, which is an ERROR. (10) If '--keep-newer-files' is PRECEDED by option '--unlink-first (lines 126 to 130), the file is preserved like in (6), which is CORRECT. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages tar depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information This is the shell script, which produced the listing above (pipe it to pr -tTi -n' 3' to get line numbers): binq3mmSKfFGW.bin Description: shell script to test gnu tar's '--keep-newer-files' option -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so:| my full name, like Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
