I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following? sed 's/[^[:alnum:]]//g'
I just can't seem to get tr -d to accept a negative matching set, but perhaps that's not possible?
Thanks in advance
-IY
Try
tr -c [:alnum:] ....
-c --complement
suomi
On 02/24/2012 01:22 PM, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following? sed 's/[^[:alnum:]]//g'
I just can't seem to get tr -d to accept a negative matching set, but perhaps that's not possible?
Thanks in advance
-IY
On 02/24/2012 10:12 PM, fedora wrote:
On 02/24/2012 01:22 PM, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following? sed 's/[^[:alnum:]]//g'
Try
tr -c [:alnum:] ....
-c --complement
suomi
Almost, but that got me on the right track. I needed:
tr --delete --complement [:alnum:]
and presto! I knew it had to be something really, really silly I was overlooking. Something such as, for example, the very first switch in the manpage.
Thanks!
On 02/24/2012 06:22 AM, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following? sed 's/[^[:alnum:]]//g'
I just can't seem to get tr -d to accept a negative matching set, but perhaps that's not possible?
Thanks in advance
-IY
aa="%1#2@3abc"; echo "${aa//[^[:alnum:]]}"
On 02/25/2012 12:43 PM, Patrick O'Callaghan wrote:
On Fri, 2012-02-24 at 21:22 +0900, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following?
[...]
You realize that tr is not a Bash builtin, right?
No, I didn't check, actually, thanks for pointing that out. The tr command is probably easier for some of the younger folks who will have to read this later on[1]. Now I'm curious and might run some tests on the two versions and see which is quicker -- though that's totally not the point with scripting (well, isn't supposed to be, anyway).
-IY
1. Rantesque continuation: ...as they seem so allergic to learning one or two sed commands that they will instead implement a parse/convert library from scratch in their favorite vanity language complete with intermediate working files and locks... and viola, new dependencies, attack vectors, opportunities for frozen jobs, etc are born.
I'm exagerrating, of course, but sadly not by much. In my current situation its far more likely that someone will look up and understand a command from coreutils than a spot of sed or my larger blobs of awk. I'm finding, to my chagrin, that what is easy and straightforward to me is clearly not easy and straightforward to the younger folks who came along after the Marketing Department decided that "all networking, ever" was synonomous with "web", and "all UIs, ever" were synonomous with "browser".
On Sat, 2012-02-25 at 17:29 +0900, 夜神 岩男 wrote:
On 02/25/2012 12:43 PM, Patrick O'Callaghan wrote:
On Fri, 2012-02-24 at 21:22 +0900, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following?
[...]
You realize that tr is not a Bash builtin, right?
No, I didn't check, actually, thanks for pointing that out. The tr command is probably easier for some of the younger folks who will have to read this later on[1]. Now I'm curious and might run some tests on the two versions and see which is quicker -- though that's totally not the point with scripting (well, isn't supposed to be, anyway).
-IY
- Rantesque continuation:
...as they seem so allergic to learning one or two sed commands that they will instead implement a parse/convert library from scratch in their favorite vanity language complete with intermediate working files and locks... and viola, new dependencies, attack vectors, opportunities for frozen jobs, etc are born.
Quite. It's a matter of developing a nose for the right combination of tools. In Unix/Linux there's rarely one right answer, but there are many many wrong ones. Good programmers learn good taste :-)
Somewhat OT:
The other day I came on a nice little problem which at first glance one would think could be solved directly in Bash:
Given a string constructed as: <prefix><marker><remainder>
Where <marker> is a string matching a (fixed) regular expression and <prefix> is arbitrary but does not match the RE, return only the <prefix>.
I convinced myself that the "=~" operator in Bash could handle this, but it made my head spin. I wound up writing 3 lines of Python (no doubt the Perlistas out there could do it in one). It not only worked but it's obviously correct, a property not to be sneezed at.
poc
2012/2/25 夜神 岩男 supergiantpotato@yahoo.co.jp:
On 02/25/2012 12:43 PM, Patrick O'Callaghan wrote:
On Fri, 2012-02-24 at 21:22 +0900, 夜神 岩男 wrote:
I'm trying to move a script from invoking lots of sed and awk to bash builtins and I'm stumped on something I'm sure is simple.
Is there a tr equivalent to the following?
[...]
You realize that tr is not a Bash builtin, right?
No, I didn't check, actually, thanks for pointing that out. The tr command is probably easier for some of the younger folks who will have to read this later on[1]. Now I'm curious and might run some tests on the two versions and see which is quicker -- though that's totally not the point with scripting (well, isn't supposed to be, anyway).
-IY
- Rantesque continuation:
...as they seem so allergic to learning one or two sed commands that they will instead implement a parse/convert library from scratch in their favorite vanity language complete with intermediate working files and locks... and viola, new dependencies, attack vectors, opportunities for frozen jobs, etc are born.
Hey, come on, no need to blame that all on the younger guys.
Some of us old codgers like to do that, too.
:-/
[...]
(What seems clear one day for me is not the next. And I was hoping to grow old gracefully. :()
-- Joel Rees