Re: mkdir -p and network drives
Christopher Faylor [EMAIL PROTECTED] writes: Except that it can't be made to work correctly due to a bash bug. Which Bash bug is that? Bash bugs can be fixed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
suggesting small improvement
I'm suggesting a small and simple addition to `cut` options.
Sometimes it is very useful to add some text around each line of `cut`
output in a pipeline. Most people use `sed` or something as big as `sed`,
but it would be much better if you can add this text directly in cut
options. Furthermore, `cut` would be suitable for simple concatenating
of strings around any input - for example output from `expr match`.
I suggest these options to be added:
-A, --output-before=STRING output STRING before each line
-Z, --output-after=STRING output STRING after each line
As a source I used `cut.c` from
ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz
, and I'm supplying the unified diff below.
Here is an example of a pipeline, that I recently used with patched `cut`:
ls -1|cut -d '.' -f 1 -A 'INSERT INTO mytable(file) VALUES(' -Z ');'
, so the output is SQL, suitable for direct execution. Here is the diff:
--- cut.5.3.0.c 2005-05-07 17:32:35.0 +0300
+++ cut.5.3.0.c.patched 2005-05-07 17:49:22.0 +0300
@@ -146,6 +146,12 @@
/* True if we have ever read standard input. */
static bool have_read_stdin;
+/* The before and after result parts in output. */
+static char *output_before_string;
+static bool output_before_specified;
+static char *output_after_string;
+static bool output_after_specified;
+
#define HT_RANGE_START_INDEX_INITIAL_CAPACITY 31
/* The set of range-start indices. For example, given a range-spec list like
@@ -172,6 +178,8 @@
{only-delimited, no_argument, 0, 's'},
{output-delimiter, required_argument, 0, OUTPUT_DELIMITER_OPTION},
{complement, no_argument, 0, COMPLEMENT_OPTION},
+ {output-before, required_argument, 0, 'A'},
+ {output-after, required_argument, 0, 'Z'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{0, 0, 0, 0}
@@ -212,6 +220,10 @@
or fields.\n\
), stdout);
fputs (_(\
+ -A, --output-before=STRING output STRING before each line\n\
+ -Z, --output-after=STRING output STRING after each line\n\
+), stdout);
+ fputs (_(\
-s, --only-delimiteddo not print lines not containing delimiters\n\
--output-delimiter=STRING use STRING as the output delimiter\n\
the default is to use the input delimiter\n\
@@ -543,6 +555,11 @@
if (c == '\n')
{
+ if(output_after_specified) {
+ fwrite (output_after_string, sizeof (char),
+ strlen(output_after_string), stdout)
+ ;
+ }
putchar ('\n');
byte_idx = 0;
print_delimiter = false;
@@ -557,6 +574,13 @@
{
bool range_start;
bool *rs = output_delimiter_specified ? range_start : NULL;
+ if(byte_idx==0) {
+ if(output_before_specified) {
+ fwrite (output_before_string, sizeof (char),
+ strlen(output_before_string), stdout)
+ ;
+ }
+ }
if (print_kth (++byte_idx, rs))
{
if (rs *rs print_delimiter)
@@ -580,6 +604,7 @@
size_t field_idx = 1;
bool found_any_selected_field = false;
bool buffer_first_field;
+ bool output_before = false;
c = getc (stream);
if (c == EOF)
@@ -626,9 +651,24 @@
}
else
{
+ if(output_before_specified) {
+ fwrite (output_before_string, sizeof (char),
+ strlen(output_before_string), stdout)
+ ;
+ output_before=true;
+ }
+ if (field_1_buffer[n_bytes - 1] != '\n')
fwrite (field_1_buffer, sizeof (char), n_bytes, stdout);
+ else
+ fwrite (field_1_buffer, sizeof (char), n_bytes-1,
stdout)
+ ;
+ if(output_after_specified) {
+ fwrite (output_after_string, sizeof (char),
+ strlen(output_after_string), stdout)
+ ;
+ }
/* Make sure the output line is newline terminated. */
- if (field_1_buffer[n_bytes - 1] != '\n')
+ /* if (field_1_buffer[n_bytes - 1] != '\n') */ /* newline removed anyway
*/
putchar ('\n');
}
continue;
@@ -636,6 +676,12 @@
if (print_kth (1, NULL))
{
/* Print the field, but not the trailing delimiter. */
+ if(output_before_specified) {
+ fwrite (output_before_string, sizeof
(char),
+ strlen(output_before_string),
Re: DD converts LF - CR / LF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 5/6/2005 12:01 PM: That looks pretty complicated. How about if we just rely on open and fcntl to do the work? If they don't work, they should. I installed this into coreutils: 2005-05-06 Paul Eggert [EMAIL PROTECTED] * NEWS: dd has new iflag= and oflag= flags binary and text. * doc/coreutils.texi (dd invocation): Document it. * src/dd.c (flags, usage): Support it. That's okay for a start, but it now defaults to the underlying mount mode when the user does not specify binary or text. In my opinion, dd should default to binary when neither text nor binary is specified (of course, that makes iflag=binary pretty much a no-op). - -- 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 iD8DBQFCfNtI84KuGfSFAYARAvJTAJ9qZymfD8tj84OIFBORuo1+Nyix5wCfXoqQ R21yy4vx9YA1YIDr5oHG7MI= =wjhL -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Fwd: Strange-Dangerous behaviour in Cygwin]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Relevant clips from this cygwin bug report. When tty settings are weird (I'm not sure whether the bug is in cygwin, xterm, or just bad tty settings that could be reproduced elsewhere), backspace only repositions the cursor on screen, so that the actual buffer read by yesno() can contain y\bn instead of n. Is it possible for lib/yesno.c to be a little more paranoid and check that there are not embedded characters normally used in terminal editing that would undo the first character? - Original Message Subject: Strange-Dangerous behaviour in Cygwin Date: Sat, 07 May 2005 17:52:10 +0200 (MET DST) From: Angelo Graziosi [EMAIL PROTECTED] To: cygwin@cygwin.com, [EMAIL PROTECTED] I discovered the following strange behaviour in bash and xterm (startxwin) shells: Suppose having alias rm='rm -i' alias cp='cp -i -p' alias mv='mv -i' then rm foo.txt writes rm: remove regular file `foo.txt'? Suppose that I does not want to remove it but mistaking I type y rm: remove regular file `foo.txt'? y Before the RETURN, I see the error so I correct, with BACKSPACE, y in n: BACKSPACE does not delete y as aspected but it only shifts the cursor on y and when I type n and then RETURN the file foo.txt is REMOVED! - -- 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 iD8DBQFCfOsh84KuGfSFAYARAshbAJ9ryQbHUu1+3cAN2pWiMY+ElmeR/wCeMAs3 gp1Dstsp/0gDFvup0MTauJY= =2MBv -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mkdir -p and network drives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/7/2005 9:43 AM: Which Bash bug is that? Bash is the most important program for which 'that chdir(//) is currently no different from chdir(/)'. Is that a bug in bash or in cygwin, though? The comments for cygwin bash-2.05b-17 mention that a patch from Corinna Vinschen was applied to avoid turning '/' into '//' when converting/checking path. And `strace bash -c 'chdir //' shows: 32 20141553 [main] bash 1564 mount_info::conv_to_posix_path: // = conv_to_posix_path (//) 112 20141665 [main] bash 1564 chdir: dir '//' 29 20141694 [main] bash 1564 normalize_posix_path: src // 30 20141724 [main] bash 1564 normalize_posix_path: / = normalize_posix_path (//) 29 20141753 [main] bash 1564 mount_info::conv_to_win32_path: conv_to_win32_path (/) 32 20141785 [main] bash 1564 set_flags: flags: binary (0x2) 65 20141850 [main] bash 1564 mount_info::conv_to_win32_path: src_path /, dst c:\cygwin, flags 0xA, rc 0 89 20141939 [main] bash 1564 symlink_info::check: not a symlink 32 20141971 [main] bash 1564 symlink_info::check: 0 = symlink.check (c:\cygwin, 0x22E6D0) (0xA) 32 20142003 [main] bash 1564 path_conv::check: this-path(c:\cygwin), has_acls(1) 76 20142079 [main] bash 1564 chdir: 0 = chdir() cygheap-cwd.posix '/' native 'c:\cygwin' And this simple trace backs that up: $ cd // $ pwd // $ /bin/pwd / So it was the cygwin normalization code that turned '//' into '/', while bash thinks the current dir is '//'. What breaks if the cygwin chdir() normalization code is changed to not turn '//' into '/'? Our track record for getting cygwin fixes into bash has been mixed. I believe that someone has tried to get this fixed previously, along with an even more serious problem with bash getting confused by quick pid reuse but I believe that both problem still exist in bash 3.0. Does bash 3.0 still have the bug that Corinna's patch to 2.05b fixed? At any rate, there is no official cygwin bash 3.0, because there has still been no volunteer to step up and produce a cygwin compilation of bash. - -- 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 iD8DBQFCfPX184KuGfSFAYARAtRIAKDYJxaPVMFBvTBky1Pn0Ql2C9YM8wCggSWm eGq3zgHS7Slnz12CrIsApTs= =/1q1 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Fwd: Strange-Dangerous behaviour in Cygwin]
Eric Blake [EMAIL PROTECTED] wrote: Relevant clips from this cygwin bug report. When tty settings are weird (I'm not sure whether the bug is in cygwin, xterm, or just bad tty settings that could be reproduced elsewhere), backspace only repositions the cursor on screen, so that the actual buffer read by yesno() can contain y\bn instead of n. Is it possible for lib/yesno.c to be a little more paranoid and check that there are not embedded characters normally used in terminal editing that would undo the first character? I don't think changing yesno would be appropriate in this case. What if the string is n\by? What if \b is not the erase character? What if the string is yes and `e' is the `erase' character? Should it handle both DEL and ERASE characters? Should it also handle word-erase and line-erase characters? I know you said `normally used...', so I assume you wanted something simple, befitting yesno's status, but I don't see an appropriate way to solve the problem by changing yesno. Alternative opinions (or patches to yesno.c) welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: DD converts LF - CR / LF
2005-05-06 Paul Eggert [EMAIL PROTECTED] * NEWS: dd has new iflag= and oflag= flags binary and text. * doc/coreutils.texi (dd invocation): Document it. * src/dd.c (flags, usage): Support it. That's okay for a start, but it now defaults to the underlying mount mode when the user does not specify binary or text. In my opinion, dd should default to binary when neither text nor binary is specified (of course, that makes iflag=binary pretty much a no-op). I agree, DD should default to binary in any case. Well, I'll look foreward to the Cywin release of coreutils-5.3.0-6 to see which patch will make it ;-) -- Sebastian Schuberth ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
