>> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
<snip>
>>> Well, when I have a string value in a shell variable and want to
>>> manipulate
>>> that string like here, I try to use shell builtins first. I do *not*
>>> printf the quoted variable value so that I can pipe it into awk, let awk
>>> do the wasteful job of processing one line, and then write awk's stdout
>>> back to a
>>> shell variable. KISS. I have showed how simple and still efficient it
>>> can be.
>> If you care to check back earlier in this thread, using the shell builtin
>> for that is exactly what I recommended and I never mentioned awk as an
>> alternative. I did show an alternative sed solution that I said I would
>> not use.
> But *first*, in <news:201209111728182493@webuse.net>, you recommended to use
> awk. You have been insisting to use awk in that subtread ever since.
> Only *after* I posted a shell-only solution and Chris F.A. Johnson disputed
> your unfounded statement there, you conceded that it could be done in the
> shell.
> Why?
Nonsense, read the thread again as you're confusing 2 very different things. I advocated using awk for non-trivial text processing applications but using a shell construct if you just want to tweak a string in the middle of a shell script. I never once advocated doing something like echoing a string to awk to modify the string and then reading the result back into a variable as you're suggesting I did.
>>>>>> Forcing yourself to stick with only bash builtins or whatever you
>>>>>> think constitutes "doing it in bash" is just pointless (no offense).
>>>>> The OP is asking for a shell solution. You are the one forcing on
>>>>> them an awk solution, claiming that not using awk is a problem.
>>>> You can call awk from the shell just as you can sed, grep, etc. Posters
>>>> asking for a shell solution rarely are asking for a solution only using
>>>> shell builtins and even when they are it's usually because they haven't
>>>> thought about the alternatives.
>>> Or because they do not care because they have with the command shell a
>>> rather decent programming language already, and are posting to the
>>> newsgroup dealing with *shell* scripting. You are projecting.
>> No, it happens VERY frequently that someone posts "how can I do X in
>> shell" or "how can I do Y with sed" and after being asked they admit that
>> they really couldn't care less what tools/language the solution uses as
>> long as it's something they can call from their shell.
> Prove that it happens more frequently than the opposite.
Read posts to the NG over the past several years. QED.
Prove that this
> newsgroup exists primarily not to discuss the shell, but solutions that
> *require* more than the shell.
"the shell" does not mean "only shell builtins", it means "the shell".
Hint: Read the newsgroup name, tagline and
> charter.
comp.unix.shell. It's about UNIX shell which includes tools available to call from the shell. You aren't seriously suggesting we exclude all non-shell-builtins from discussions in this NG are you? If the NG was named comp.shell.builtins you might have a case but then it wouldn't matter because no-one would bother posting to that NG.
I have already pointed out that there is a newsgroup for awk
> programming, which should indicate to you that awk programming is not the
> primary topic of this newsgroup.
There is no NG for sed. sed is not a shell builtin. Therefore by your logic no-one must ever discuss sed in any NG, right?
>>> This is comp.unix.*shell*, after all, so the possibilities of using shell
>>> syntax and shell builtins should be first on a regular's mind. If you
>>> want to discuss awk, there is comp.lang.*awk* instead. If you want to
>>> discuss perl, there is comp.lang.*perl*.ALL. And so on.
>> So you'll be advocating comp.lang.sed, comp.lang.diff, etc. for all the
>> other commonly used shell commands? No, the first thing on people minds
>> should be how to get the job done as quickly and succinctly as possible
>> using the commands available in their shell and that includes grep, diff,
>> sed, awk, etc. Making use of only shell builtins a priority would be like
>> a construction worker trying to do everything with a hammer and
>> screwdriver rather than picking up a nail gun and drill.
Ed Morton wrote:
> On 9/18/2012 4:37 AM, Thomas 'PointedEars' Lahn wrote:
>> Ed Morton wrote:
>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> <snip>
>>>> Well, when I have a string value in a shell variable and want to
>>>> manipulate
>>>> that string like here, I try to use shell builtins first. I do *not*
>>>> printf the quoted variable value so that I can pipe it into awk, let
>>>> awk do the wasteful job of processing one line, and then write awk's
>>>> stdout back to a
>>>> shell variable. KISS. I have showed how simple and still efficient it
>>>> can be.
>>> If you care to check back earlier in this thread, using the shell
>>> builtin for that is exactly what I recommended and I never mentioned awk
>>> as an alternative. I did show an alternative sed solution that I said I
>>> would not use.
>> But *first*, in <news:201209111728182493@webuse.net>, you recommended to
>> use awk. You have been insisting to use awk in that subtread ever since.
>> Only *after* I posted a shell-only solution and Chris F.A. Johnson
>> disputed your unfounded statement there, you conceded that it could be
>> done in the shell.
>> Why?
> Nonsense, read the thread again as you're confusing 2 very different
> things. I advocated using awk for non-trivial text processing applications
> but using a shell construct if you just want to tweak a string in the
> middle of a shell script. I never once advocated doing something like
> echoing a string to awk to modify the string and then reading the result
> back into a variable as you're suggesting I did.
That is correct; you actually suggested creating from the string value a text file to be processed by awk instead, which is even more illogical than piping the string echo into awk, or using shell built-ins instead. And you called that "a working solution", showing that you did not understand the OP's problem correctly in the first place.
>>>>>>> Forcing yourself to stick with only bash builtins or whatever you
>>>>>>> think constitutes "doing it in bash" is just pointless (no offense).
>>>>>> The OP is asking for a shell solution. You are the one forcing on
>>>>>> them an awk solution, claiming that not using awk is a problem.
>>>>> You can call awk from the shell just as you can sed, grep, etc.
>>>>> Posters asking for a shell solution rarely are asking for a solution
>>>>> only using shell builtins and even when they are it's usually because
>>>>> they haven't thought about the alternatives.
>>>> Or because they do not care because they have with the command shell a
>>>> rather decent programming language already, and are posting to the
>>>> newsgroup dealing with *shell* scripting. You are projecting.
>>> No, it happens VERY frequently that someone posts "how can I do X in
>>> shell" or "how can I do Y with sed" and after being asked they admit
>>> that they really couldn't care less what tools/language the solution
>>> uses as long as it's something they can call from their shell.
>> Prove that it happens more frequently than the opposite.
> Read posts to the NG over the past several years. QED.
(Fallacy: Shifting the burden of proof.)
A *sound* argumentation does not work that way. *You* claim, *you* prove.
Granted, you have not claimed that the majority of problems would require a not-shell-only solution; you have used the weasel words "VERY frequently".
Which is fallacious, of course. So I gave you an opportunity here to quantify the postings and thereby substantiate your argument. You did not use it.
>> Prove that this newsgroup exists primarily not to discuss the shell, but
>> solutions that *require* more than the shell.
> "the shell" does not mean "only shell builtins", it means "the shell".
I concur. And it does not mean "awk only" either. There is the flaw in your approach and your argument.
>> Hint: Read the newsgroup name, tagline and charter.
> comp.unix.shell. It's about UNIX shell which includes tools available to
> call from the shell. You aren't seriously suggesting we exclude all
> non-shell-builtins from discussions in this NG are you?
That is correct, I am not. You are still misconstruing what I said.
> If the NG was named comp.shell.builtins you might have a case but then it
> wouldn't matter because no-one would bother posting to that NG.
Argument at ridicule again.
>> I have already pointed out that there is a newsgroup for awk programming,
>> which should indicate to you that awk programming is not the primary
>> topic of this newsgroup.
> There is no NG for sed. sed is not a shell builtin. Therefore by your
> logic no-one must ever discuss sed in any NG, right?
No, because you continue to misconstrue my argument by ignoring the
qualifiers I have always put in there.
>>>> This is comp.unix.*shell*, after all, so the possibilities of using
>>>> shell syntax and shell builtins should be first on a regular's mind. >>>> If you want to discuss awk, there is comp.lang.*awk* instead. If you
>>>> want to discuss perl, there is comp.lang.*perl*.ALL. And so on.
>>> So you'll be advocating comp.lang.sed, comp.lang.diff, etc. for all the
>>> other commonly used shell commands? No, the first thing on people minds
>>> should be how to get the job done as quickly and succinctly as possible
>>> using the commands available in their shell and that includes grep,
>>> diff, sed, awk, etc. Making use of only shell builtins a priority would
>>> be like a construction worker trying to do everything with a hammer and
>>> screwdriver rather than picking up a nail gun and drill.
>> Argument at ridicule again.
> You're embarrassing yourself, give it up.
Argumentum ad hominem, at last.
I am pointing out to you the flaws in your approach and your argumentation defending it. If I stop doing that, they will still be in there.
-- PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
>> On 9/18/2012 4:37 AM, Thomas 'PointedEars' Lahn wrote:
>>> Ed Morton wrote:
>>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
>> <snip>
>>>>> Well, when I have a string value in a shell variable and want to
>>>>> manipulate
>>>>> that string like here, I try to use shell builtins first. I do *not*
>>>>> printf the quoted variable value so that I can pipe it into awk, let
>>>>> awk do the wasteful job of processing one line, and then write awk's
>>>>> stdout back to a
>>>>> shell variable. KISS. I have showed how simple and still efficient it
>>>>> can be.
>>>> If you care to check back earlier in this thread, using the shell
>>>> builtin for that is exactly what I recommended and I never mentioned awk
>>>> as an alternative. I did show an alternative sed solution that I said I
>>>> would not use.
>>> But *first*, in <news:201209111728182493@webuse.net>, you recommended to
>>> use awk. You have been insisting to use awk in that subtread ever since.
>>> Only *after* I posted a shell-only solution and Chris F.A. Johnson
>>> disputed your unfounded statement there, you conceded that it could be
>>> done in the shell.
>>> Why?
>> Nonsense, read the thread again as you're confusing 2 very different
>> things. I advocated using awk for non-trivial text processing applications
>> but using a shell construct if you just want to tweak a string in the
>> middle of a shell script. I never once advocated doing something like
>> echoing a string to awk to modify the string and then reading the result
>> back into a variable as you're suggesting I did.
> That is correct; you actually suggested creating from the string value a
> text file to be processed by awk instead, which is even more illogical than
> piping the string echo into awk, or using shell built-ins instead. And you
> called that "a working solution", showing that you did not understand the
> OP's problem correctly in the first place.
What the heck are you talking about "creating from the string value a text file to be processed by awk"??? Also, the OP specifically posted that the awk script solved his problem (see below) so I think that's a pretty good indication that i did understand it.
Here's exactly what I said in the posts I think you're referring to:
#On 9/11/2012 12:28 PM, Ed Morton wrote:
# Carlo Zanziba <zanzibaNOS...@NOSPAMlibero.it> wrote:
#
#> Hello,
#>
#> Suppose I have such string
#>
#> str="first. second; third. lost? maybe! no"
#>
#> I'd want to turn every first character, and every non-blank character
#> after dot, question and exclamative marks to capital, so that it turns to
#>
#> First. Second; third. Lost? Maybe! No
#>
#> --------------
#> As add-on, consider that any inner text enclosed into double quotes
#> should be capitalized, e.g.
#>
#> str="first. second; third. \"the prince of arabia\" lost? maybe! no"
#>
#> turned to
#>
#> First. Second; Third. "The Prince Of Arabia" lost? Maybe! No
#>
#
# Simplest (and maybe only) thing is just to do it one char at a time:
#
# $ cat file
# first. second; third. "the prince of arabia" lost? maybe! no
# $ cat tst.awk
# BEGIN{ FS="" }
# {
# prev = lastNonBlank = ""
# for (i=1; i<=NF; i++) {
#
# curr = $i
#
# if (curr == "\"") {
# inQuotes = !inQuotes
# }
#
# if ( (prev == "") ||
# (lastNonBlank ~ /[.?!]/) ||
# (inQuotes && (prev !~ /[[:alpha:]]/)) ) {
# curr = toupper(curr)
# }
#
# if ( curr !~ /[[:blank:]]/ ) {
# lastNonBlank = curr
# }
# prev = curr
#
# printf "%c", curr
# }
# print ""
# }
# $ awk -f tst.awk file
# First. Second; third. "The Prince Of Arabia" lost? Maybe! No
#
#On 9/12/2012 5:42 PM, Ed Morton wrote:
# If you're just talking about one-liners like:
#
# $ x="foo/bar"; echo "${x%/*}"
# foo
#
# instead of:
#
# $ x="foo/bar"; echo "$x" | sed 's?/.*??'
# foo
#
# then I'd do that mainly because it's briefer rather than faster
and here's the OPs final response to the thread:
#On 9/13/2012 2:02 AM, Carlo Zanziba wrote:
# Il 12/09/2012 12:21, Ed Morton ha scritto:
#> On 9/12/2012 1:13 AM, Carlo Zanziba wrote:
#>> Thanks everybody. I was afraid my supposition was too far from what
#>> bash could
#>> give me.
#>>
#>> In any case, I appreciated your efforts.
#>
#> You did see that I gave you a working solution, right?
#
# Sure. It works, and fast!
#
# Thanks.
#
# Carlo
Are you confusing my responses with someone else's? I don't recall seeing an alternative shell-builtin-only solution posted by you or anyone else but if you have one then please do share, otherwise just stop whining as you're really making no sense trying to attribute statements to me that I never made and complaining about perfectly reasonable working solutions, especially when no alternative has been posted.
Ed Morton wrote:
> On 9/18/2012 9:23 AM, Thomas 'PointedEars' Lahn wrote:
>> Ed Morton wrote:
>>> On 9/18/2012 4:37 AM, Thomas 'PointedEars' Lahn wrote:
>>>> Ed Morton wrote:
>>>>> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
>>> <snip>
>>>> But *first*, in <news:201209111728182493@webuse.net>, you recommended
>>>> to use awk. You have been insisting to use awk in that subtread ever
>>>> since.
>>>> Only *after* I posted a shell-only solution and Chris F.A. Johnson
>>>> disputed your unfounded statement there, you conceded that it could be
>>>> done in the shell.
>>>> Why?
>>> Nonsense, read the thread again as you're confusing 2 very different
>>> things. I advocated using awk for non-trivial text processing
>>> applications but using a shell construct if you just want to tweak a
>>> string in the middle of a shell script. I never once advocated doing
>>> something like echoing a string to awk to modify the string and then
>>> reading the result back into a variable as you're suggesting I did.
>> That is correct; you actually suggested creating from the string value a
>> text file to be processed by awk instead, which is even more illogical
>> than piping the string echo into awk, or using shell built-ins instead. >> And you called that "a working solution", showing that you did not
>> understand the OP's problem correctly in the first place.
> What the heck are you talking about "creating from the string value a text
> file to be processed by awk"???
See below.
> Also, the OP specifically posted that the awk script solved his problem
> (see below) so I think that's a pretty good indication that i did
> understand it.
No, it is pretty good indication that the OP thought that, as you were resorting to awk immediately, there were no other possibilities, particularly none with only the shell. Which they made clear in their other followup (see below). Are you simply not paying attention, or whom are you trying to fool here?
> Here's exactly what I said in the posts I think you're referring to:
> #On 9/11/2012 12:28 PM, Ed Morton wrote:
> # Carlo Zanziba <zanzibaNOS...@NOSPAMlibero.it> wrote:
> #
> #> Hello,
> #>
> #> Suppose I have such string
> #>
> #> str="first. second; third. lost? maybe! no"
> #> […]
So they have a string value in a sh-based shell (which, as it turned out, is bash). And they want to transform that string:
| I'd want to turn every first character, and every non-blank character | after dot, question and exclamative marks to capital, so that it turns to
| | First. Second; third. Lost? Maybe! No
A plain and simple problem. From which in your solution, out of thin air, it emerges a text file containing the string value …
> # $ cat file
> # first. second; third. "the prince of arabia" lost? maybe! no
> # $ cat tst.awk
> # BEGIN{ FS="" }
> # {
> […]
> and here's the OPs final response to the thread:
> #On 9/13/2012 2:02 AM, Carlo Zanziba wrote:
> # Il 12/09/2012 12:21, Ed Morton ha scritto:
> #> On 9/12/2012 1:13 AM, Carlo Zanziba wrote:
> #>> Thanks everybody. I was afraid my supposition was too far from
> #>> what bash could
> #>> give me.
> #>>
> #>> In any case, I appreciated your efforts.
> #>
> #> You did see that I gave you a working solution, right?
> #
> # Sure. It works, and fast!
> […]
Of course it works in certain situations. Nobody doubted that. The problem that you still fail to see lies elsewhere: If all you know is a hammer, every problem looks like a nail.
> Are you confusing my responses with someone else's? I don't recall seeing
> an alternative shell-builtin-only solution posted by you or anyone else
> but if you have one then please do share, otherwise just stop whining as
> you're really making no sense trying to attribute statements to me that I
> never made and complaining about perfectly reasonable working solutions,
> especially when no alternative has been posted.
Here it comes:
| From: Carlo Zanziba <zanzibaNOS...@NOSPAMlibero.it>
| Newsgroups: comp.unix.shell
| Subject: Re: Pattern matching within ,, and ^^ parser
| Date: Wed, 12 Sep 2012 08:13:19 +0200
| […]
| Message-ID: <k2p961$6f...@tdi.cu.mi.it>
| References: <k2mp5u$ed...@tdi.cu.mi.it>
| […]
| | Thanks everybody. I was afraid my supposition was too far from what bash | could give me.
| […]
And that is simply not true. However, your posting and others, that did not even mention that there was a solution without external tools, mislead the OP into believing so. More, the OP have been mislead into believing that the not-shell-only solutions were without any compatibility issues because compatibility issues also were conveniently left out in their presentation.
As a result, not only have they not learned to leverage the power of sh-
based shells, in particular bash, they also believe now they using issue-
free code. Fortunately in this case there were other people to point out that there was a shell/bash solution, and that the awk solution was not without issues itself – as there is not only one awk; where in contrast there is only one (GNU) bash, albeit in different versions which is not relevant here. But what if there had not been?
*That* is a Bad Thing, particularly when in originates in comp.unix.*shell*.
The tools are there, and should be discussed *here* as such, to *complement* the shell command language; _not_ to replace it.
To point that out to the obviously extremely short-sighted, and to ask for reconsideration of approaches, constitutes anything but whining.
BTW: Trim your quotes to the relevant minimum next time, please.
On 9/18/2012 10:15 AM, Thomas 'PointedEars' Lahn wrote:
> Ed Morton wrote:
<snip>
>> Also, the OP specifically posted that the awk script solved his problem
>> (see below) so I think that's a pretty good indication that i did
>> understand it.
> No, it is pretty good indication that the OP thought that, as you were
> resorting to awk immediately, there were no other possibilities,
> particularly none with only the shell. Which they made clear in their other
> followup (see below). Are you simply not paying attention, or whom are you
> trying to fool here?
Now who's projecting?
At the end of the day - no-one has posted a solution using just shell builtins. If you think such a solution is in some way better than the awk one, then please do post it. The "proof of concept" you posted elsethread doesn't even come close to solving the problem (particularly the part about capitalizing the first letter of every word within quotes) but I'm sure you know that very well or you'd have produced a working solution based on that.
>> Here's exactly what I said in the posts I think you're referring to:
>> #On 9/11/2012 12:28 PM, Ed Morton wrote:
>> # Carlo Zanziba <zanzibaNOS...@NOSPAMlibero.it> wrote:
>> #
>> #> Hello,
>> #>
>> #> Suppose I have such string
>> #>
>> #> str="first. second; third. lost? maybe! no"
>> #> […]
> So they have a string value in a sh-based shell (which, as it turned out, is
> bash). And they want to transform that string:
> | I'd want to turn every first character, and every non-blank character
> | after dot, question and exclamative marks to capital, so that it turns to
> |
> | First. Second; third. Lost? Maybe! No
> A plain and simple problem. From which in your solution, out of thin air,
> it emerges a text file containing the string value …
>> # $ cat file
>> # first. second; third. "the prince of arabia" lost? maybe! no
THAT'S what you're whining about? That I used a file to contain the input rather than a here document or a pipe or just passing a string to the awk script??? I assumed the OP wasn't pulling strings out of thin air or hard-coding them into his script otherwise it'd be a pretty pointless exercise. If that had been any kind of issue it's obviously trivial to use some other way of inputting the string to the awk script.
> … that you can process with awk then, of course:
>> # $ cat tst.awk
>> # BEGIN{ FS="" }
>> # {
>> […]
>> and here's the OPs final response to the thread:
>> #On 9/13/2012 2:02 AM, Carlo Zanziba wrote:
>> # Il 12/09/2012 12:21, Ed Morton ha scritto:
>> #> On 9/12/2012 1:13 AM, Carlo Zanziba wrote:
>> #>> Thanks everybody. I was afraid my supposition was too far from
>> #>> what bash could
>> #>> give me.
>> #>>
>> #>> In any case, I appreciated your efforts.
>> #>
>> #> You did see that I gave you a working solution, right?
>> #
>> # Sure. It works, and fast!
>> […]
> Of course it works in certain situations. Nobody doubted that. The problem
> that you still fail to see lies elsewhere: If all you know is a hammer,
> every problem looks like a nail.
Again, please post the better solution.
<further pointless ramblings snipped>
> BTW: Trim your quotes to the relevant minimum next time, please.
Done. Look, if you think a shell-builtin-only solution is appropriate to solve the OPs problem then just post it so we can compare or stop whining about the awk solution.
Ed Morton wrote:
> On 9/18/2012 10:15 AM, Thomas 'PointedEars' Lahn wrote:
>> Ed Morton wrote:
> <snip>
>>> Also, the OP specifically posted that the awk script solved his problem
>>> (see below) so I think that's a pretty good indication that i did
>>> understand it.
>> No, it is pretty good indication that the OP thought that, as you were
>> resorting to awk immediately, there were no other possibilities,
>> particularly none with only the shell. Which they made clear in their
>> other followup (see below). Are you simply not paying attention, or whom
>> are you trying to fool here?
> Now who's projecting?
Not me. People who are not versed enough to know the shell command language will necessarily be satisfied with any response perceived as a solution that comes along, even if that includes using external tools.
You can observe that kind of beginner's behavior all over the Net. For example, if you give a JavaScript novice an unnecessarily bloated jQuery solution to a trivial DOM problem, they will use that. They will not question the underlying bad approach and code quality, because they do not – they cannot – know about that at this point in the learning curve. And of course they will say "it works" – in the handful of environments (if you are lucky) and the one circumstance they have tested it with.
> At the end of the day - no-one has posted a solution using just shell
> builtins.
I have. It was only not a Bourne Shell-compatible or POSIX:2008 shell builtin; it was one that is supported by bash, ksh, and probably other shells since several versions, though. And I had posted it particularly as followup to the OP's false statement that *bash*'s shell command language alone could not do it.
> If you think such a solution is in some way better than the awk
> one, then please do post it.
Maybe later. Whether I post it or not is very well beside the point, though.
> The "proof of concept" you posted elsethread doesn't even come close to
> solving the problem
That is why it is a proof of *concept* and not a complete solution. It gives the dedicated reader something to think about and build on. What matters is that it shows how it could be done *without* further assumptions and dependencies.
> (particularly the part about capitalizing the first letter of every word
> within quotes)
That was optional, but I have also indicated in my first followup how that could be done with shell builtins.
> but I'm sure you know that very well or you'd have produced a working
> solution based on that.
>>> Here's exactly what I said in the posts I think you're referring to:
>>> #On 9/11/2012 12:28 PM, Ed Morton wrote:
>>> # Carlo Zanziba <zanzibaNOS...@NOSPAMlibero.it> wrote:
>>> #
>>> #> Hello,
>>> #>
>>> #> Suppose I have such string
>>> #>
>>> #> str="first. second; third. lost? maybe! no"
>>> #> […]
>> So they have a string value in a sh-based shell (which, as it turned out,
>> is bash). And they want to transform that string:
>> | I'd want to turn every first character, and every non-blank character
>> | after dot, question and exclamative marks to capital, so that it turns
>> | to
>> |
>> | First. Second; third. Lost? Maybe! No
>> A plain and simple problem. From which in your solution, out of thin
>> air, it emerges a text file containing the string value …
>>> # $ cat file
>>> # first. second; third. "the prince of arabia" lost? maybe! no
> THAT'S what you're whining about? That I used a file to contain the input
> rather than a here document or a pipe or just passing a string to the awk
> script???
I am pointing out to you again, because despite all my efforts so far you still fail (or refuse?) to see it, that your so-called solution adds more dependencies than the problem originally had: a text file, and a specific version or range of versions of a specific implementation or a specific range of implementations of awk. And it does so *unnecessarily*, in a newsgroup where awk should be merely an additional tool.
> I assumed the OP wasn't pulling strings out of thin air
There you go. Where is the basis for that assumption? And where is the basis for the assumption that, assuming that they are using a text file, the text file contains only that line, or is in a suitable format?
> or hard-coding them into his script otherwise it'd be a pretty pointless
> exercise.
They may very well have retrieved the string value in the script from elsewhere. Have you even considered that?
> If that had been any kind of issue it's obviously trivial to use
> some other way of inputting the string to the awk script.
And there we have the previously criticized pipe-into-awk approach as your so-called solution for a problem that does not even call for using awk in the first place. Which is not the first time (in fact, it is hard to find a posting here where you do not suggest *only* awk), and *that* is what I do mind in comp.unix.*shell*. The newsgroup is about using the *shell*, _not_ only awk. If I want to read only awk-only postings, I can read comp.lang.awk already.
-- PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
<all rehashed nonsense snipped>
1) I posted an awk script that solves the OPs problem (see below).
2) You posted a few trivial lines of bash builtins that do not solve the OPs
problem (also see below) and cannot be expanded upon to do so without major
rework and enhancement.
3) We agree that the NG comp.unix.shell is about all shell solutions, not just
those involving shell builtins. The fact that I choose to respond mainly to the
threads where an awk solution is reasonable and others choose to respond to
threads where a perl solution is reasonable, etc. based on where we think we
have most to contribute in no way diminishes the NG.
Have a nice day.
Ed.
---------------------------------------
Input:
first. second; third. "the prince of arabia" lost? maybe! no
---------------------------------------
Desired Output:
First. Second; third. "The Prince Of Arabia" lost? Maybe! No
---------------------------------------
Working awk solution (not using a file for input at your request):
$ cat awk.bash
str='first. second; third. "the prince of arabia" lost? maybe! no'
Ed Morton wrote:
> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> <all rehashed nonsense snipped>
Score adjusted.
> 1) I posted an awk script that solves the OPs problem (see below).
You really don't get it, do you?
> 2) You posted a few trivial lines of bash builtins
Trivial, indeed. To show how easy it can be if you know how.
> that do not solve the OPs problem (also see below) and cannot be expanded
> upon to do so without major rework and enhancement.
Neither can your awk solution. That is a non-argument. Another one.
> 3) We agree that the NG comp.unix.shell is about all shell solutions, not
> just those involving shell builtins. The fact that I choose to respond
> mainly to the threads where an awk solution is reasonable
Where *you* *think* an awk solution is reasonable because, basically, you know nothing else; particularly you don't know the *primary* subject of this newsgroup, the shell. You only know a hammer, and what you see is a nail.
> […] in no way diminishes the NG.
Yes, it does, if the features that the shell already has are left out of the equation and the – basically – non-shell solution is presented as the best and only one. A craftsman should learn more than how to swing a hammer.
Much more.
Since you prefer the hammer: Do you need "concept" hammered on your forehead before you get it? It was never intended as a complete solution, and the in-quotes part was defined to be *optional* ("add-on") from the start:
| As add-on, consider that any inner text enclosed into double quotes | should be capitalized, e.g.
| | str="first. second; third. \"the prince of arabia\" lost? maybe! no"
| | turned to
| | First. Second; Third. "The Prince Of Arabia" lost? Maybe! No
| | but this may prove impossible.
Of course, it is not impossible even with shell builtins.
> $ cat builtins.bash
> str='first. second; third. "the prince of arabia" lost? maybe! no'
> IFS_BAK=$IFS
> IFS='.?!'
> for sentence in $str
> do
> sentence=${sentence##[[:space:]]}
> sentence_uppercase=${sentence^[a-z]}
> str=${str/$sentence/$sentence_uppercase}
> done
> IFS=$IFS_BAK
> printf '%s\n' "$str"
> $ ./builtins.bash
> First. Second; third. "the prince of arabia" lost? Maybe! No
No, you just don't get it.
-- PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
<a whole bunch of fascinating stuff snipped>
Apologies to the community, I know I should just stop responding but it's like
picking a scab, I just can't seem to stop myself. You don't often get to see
inside a mind like PointedEars' now that Sidney Lambe has stopped posting here.
PointedEars -
a) when is it appropriate to post awk solutions in this NG?
b) who should be allowed to post awk solutions in this NG?
c) which other tools, if any, should be avoided?
> Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> <a whole bunch of fascinating stuff snipped>
> Apologies to the community, I know I should just stop responding but it's like
> picking a scab, I just can't seem to stop myself. You don't often get to see
> inside a mind like PointedEars' now that Sidney Lambe has stopped posting here.
It's better _for you_ as well, to stop replying to pointless postings.
Janis Papanagnou <janis_papanag...@hotmail.com> wrote:
> Am 19.09.2012 16:49, schrieb Ed Morton:
> > Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> > <a whole bunch of fascinating stuff snipped>
> > Apologies to the community, I know I should just stop responding but it's like
> > picking a scab, I just can't seem to stop myself. You don't often get to see
> > inside a mind like PointedEars' now that Sidney Lambe has stopped posting here.
> It's better _for you_ as well, to stop replying to pointless postings.
I know, I know. This is the end of it, honest.
I did make an interesting discovery just a minute ago though - as I mentioned
above, PointedEars ramblings reminded me a lot of Sidney Lambe, even the
anti-awk rhetoric. After making that connection I then noticed that in one of
his responses PointedEars had said "Score adjusted":
Ed Morton wrote:
> a) when is it appropriate to post awk solutions in this NG?
That depends on what an awk solution is. What I think matters is that what the shell command language already can do should not be neglected over the understandable excitement that using awk and other tools can create. AISB, one needs to know more than just a hammer.
So the approach should be "You can do this like that in the shell, but you can also do it like so with sed, awk, etc. Choose what you think, given the arguments presented so far, is best for you."
> b) who should be allowed to post awk solutions in this NG?
Everyone, with the aforementioned in mind.
> c) which other tools, if any, should be avoided?
You are still missing the point, and I am getting the impression here that you do so *intentionally*. EOD.
-- PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
