Timeline for Removing all non-ascii characters from a workflow (file)
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 29, 2024 at 15:53 | comment | added | sondra.kinsey | This answer uses LC_ALL=C for sed and awk, but not tr. Stéphane Chazelas's edits to another answer indicate that it may be required for tr in some environments as well. | |
| Dec 14, 2020 at 0:30 | comment | added | user232326 | @StéphaneChazelas tr should correctly process NUL characters according to posix: read Rationale in However, the removal of -n in a later proposal does not remove the requirement that tr correctly process NUL characters in its input stream. | |
| Dec 14, 2020 at 0:21 | comment | added | user232326 | More than a year and still no answer @StéphaneChazelas. What would be the posix way to write a tab character inside a range? some thing like $'[\t]'? That is using an also non-compliant shell feature to place a tab inside a pair of brackets []. | |
| Dec 14, 2020 at 0:17 | history | edited | user232326 | CC BY-SA 4.0 | added 22 characters in body |
| Jul 31, 2019 at 16:20 | history | edited | user232326 | CC BY-SA 4.0 | Correct awk for [^[:space:][:print:]]. |
| Jul 31, 2019 at 16:09 | history | edited | user232326 | CC BY-SA 4.0 | Correct newline processing (and comment) on awk. |
| Jul 31, 2019 at 16:02 | comment | added | user232326 | Then: The limitation of GNU sed is to fail to avoid accepting escaped characters inside bracket expressions. That is: posix compatible action is to not accept \t as a tab inside bracket expressions. Correct? . @StéphaneChazelas | |
| Jul 31, 2019 at 15:56 | comment | added | Stéphane Chazelas | Note that technically, that \0 is not POSIX (behaviour undefined), but any way awk's behaviour is unspecified if the input has NUL bytes. | |
| Jul 31, 2019 at 15:53 | comment | added | Stéphane Chazelas | [^\o0] is to match on characters other than backslash, o and 0 in POSIX sed (in all implementations but GNU sed). That's not a limitation of GNU sed but a non-compliant extension, which is why it's disabled when POSIXLY_CORRECT is in the environment). | |
| Jul 31, 2019 at 15:53 | history | edited | user232326 | CC BY-SA 4.0 | added 58 characters in body |
| Jul 31, 2019 at 15:37 | comment | added | user232326 | @StéphaneChazelas What is the limitation of GNU sed that makes the syntax GNU specific (I understand the POSIXLY_CORRECT problem). | |
| Jul 31, 2019 at 15:36 | history | edited | user232326 | CC BY-SA 4.0 | Addressing several concerns from Stéphane Chazelas in comments. |
| Oct 17, 2018 at 15:17 | history | edited | user232326 | CC BY-SA 4.0 | Note about a trailing new line added. |
| Oct 15, 2018 at 19:40 | history | edited | user232326 | CC BY-SA 4.0 | Added portable ranges. |
| Oct 15, 2018 at 12:05 | history | answered | user232326 | CC BY-SA 4.0 |