Timeline for Largest Number Printable
Current License: CC BY-SA 3.0
6 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jul 8, 2018 at 8:57 | comment | added | Bary12 | Oh, my bad, I was using Zsh, that actually had problems with the pattern not being inside a string. | |
Jul 7, 2018 at 22:05 | comment | added | Kevin Fegan |
@Bary12 --- From --help on GNU sed V 4.2.1 on my Windows 7 system: If no -e, --expression, -f, or --file option is given, then the first non-option argument is taken as the sed script to interpret. All remaining arguments are names of input files; if no input files are specified, then the standard input is read. According to that, the -e is not required in this case. In any case, if you still feel you are correct, please feel free to edit my post to reflect the new command-length, and score. I won't object.
|
|
Jul 7, 2018 at 21:54 | comment | added | Kevin Fegan |
@Bary12 - Unfortunately, I no longer have access to (bash/sed on) that system, so I can't retry the command to verify it, let alone reproduce the same output. I do recall that I would have copy/pasted the command to a bash shell on that system to collect/verify results so I'm fairly confident it worked, as-is, without the -e . I can tell you that it works, with OR WITHOUT the -e on a Windows 7 system, running GNU sed version 4.2.1, although the command needs slight modification on Windows: dir /s|sed "s/[^[:digit:]]//g"|tr -d "\r\n" (continued ---)
|
|
Jul 5, 2018 at 8:44 | comment | added | Bary12 |
You are missing a -e in your call to sed
|
|
Jan 10, 2014 at 1:59 | review | First posts | |||
Jan 10, 2014 at 2:31 | |||||
Jan 10, 2014 at 1:42 | history | answered | Kevin Fegan | CC BY-SA 3.0 |