Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.shell > #25973 > unrolled thread

a sed question

Back to article view | Back to comp.unix.shell

Contents

  a sed question Salvador Mirzo <smirzo@example.com> - 2024-12-18 16:46 -0300
    Re: a sed question John-Paul Stewart <jpstewart@personalprojects.net> - 2024-12-18 15:12 -0500
    Re: a sed question Ralf Damaschke <rwspam@gmx.de> - 2024-12-19 01:14 +0000
      Re: a sed question Salvador Mirzo <smirzo@example.com> - 2024-12-19 09:05 -0300
        Re: a sed question Ralf Damaschke <rwspam@gmx.de> - 2024-12-20 00:55 +0000
          Re: a sed question gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-20 12:44 +0000
            Re: a sed question Ralf Damaschke <rwspam@gmx.de> - 2024-12-21 00:17 +0000
              Re: a sed question Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-21 03:09 +0000
                sed... (Was: a sed question) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-21 03:36 +0000
                  Re: sed... (Was: a sed question) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-21 03:57 +0000
                    Re: sed... (Was: a sed question) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 15:38 +0100
                      Re: sed... (Was: a sed question) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 17:29 +0100
                        Re: sed... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 14:23 -0800
                          Re: sed... Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 00:33 +0100
                    Re: sed... (Was: a sed question) Lars Poulsen <lars@cleo.beagle-ears.com> - 2024-12-21 21:46 +0000
                      Re: sed... (Was: a sed question) Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-22 21:22 +0000
                Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 15:35 +0100
                Re: a sed question Ralf Damaschke <rwspam@gmx.de> - 2024-12-22 00:43 +0000
    Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-20 15:55 +0100
      Checking for right # of args in a shell script (Was: a sed question) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-20 15:11 +0000
        Re: Checking for right # of args in a shell script (Was: a sed question) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-20 16:49 +0100
          Re: Checking for right # of args in a shell script (Was: a sed question) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-20 17:43 +0000
      Re: a sed question Salvador Mirzo <smirzo@example.com> - 2024-12-21 09:17 -0300
        Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 16:19 +0100
          Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 13:41 -0800
            Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 00:50 +0100
              Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 16:26 -0800
                Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 01:41 +0100
              Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 00:31 +0000
                Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 02:06 +0100
        Re: a sed question Andy Walker <anw@cuboid.co.uk> - 2024-12-21 15:34 +0000
          Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 17:14 +0100
          Re: a sed question Salvador Mirzo <smirzo@example.com> - 2024-12-21 15:21 -0300
            Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 20:48 +0100
        Re: a sed question Helmut Waitzmann <nn.throttle@xoxy.net> - 2024-12-21 19:20 +0100
      Re: a sed question Ordatious <order@order.invalid> - 2024-12-22 09:19 +0000
        Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 19:23 +0100
    Re: a sed question Ed Morton <mortonspam@gmail.com> - 2024-12-21 08:13 -0600
      Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-21 21:09 +0000
        Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 01:02 +0100
          Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 00:28 +0000
            Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 16:36 -0800
              Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 01:52 +0000
                Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 21:09 -0800
                  Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 05:56 +0000
                    Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-21 22:55 -0800
                      Re: a sed question Eric Pozharski <apple.universe@posteo.net> - 2024-12-23 10:09 +0000
                        Re: a sed question gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-23 12:41 +0000
                          Re: a sed question Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-23 18:47 +0000
                          Re: a sed question Eric Pozharski <apple.universe@posteo.net> - 2024-12-24 11:20 +0000
            Re: a sed question Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 02:22 +0100
        Re: a sed question gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-22 01:09 +0000
        Re: a sed question Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-22 20:03 +0000
        Re: a sed question Ed Morton <mortonspam@gmail.com> - 2024-12-23 07:26 -0600
          How to solve The Miracle (was Re: a sed question) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-23 21:09 +0100
          Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-23 22:57 +0000
            Re: a sed question Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-23 15:06 -0800
              Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-24 00:28 +0000
                Re: a sed question anthk <anthk@openbsd.home> - 2025-03-23 09:45 +0000
                  Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-23 23:41 +0000
            Re: a sed question Ed Morton <mortonspam@gmail.com> - 2024-12-24 06:20 -0600
              Dealing with four-year-olds... (Was: a sed question) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-24 12:58 +0000
              Re: a sed question Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-24 20:57 +0000
                Re: a sed question Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-24 21:46 +0000
                  Arguing with a four-year-old (Was: a sed question) gazelle@shell.xmission.com (Kenny McCormack) - 2024-12-24 23:53 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#25973 — a sed question

(*) Summary

I wrote a sed script that makes a line replacement after it finds the
right spot.  So far so good.  Then I added quit command after the
change, but the quit does not seem to take effect---violating my
expectation.  I'll appreciate any help on understanding what's going on.

(*) A detailed description

I wrote this program:

--8<-------------------------------------------------------->8---
%cat make-release
#!/bin/sh
usage()
{
  printf '%s tag file\n' $0
  exit 1
}
test $# '<' 2 && usage
tag="$1"
shift
sed "/<<Release>>=/ {
 n;
 c\\
$tag
}" $*
--8<-------------------------------------------------------->8---

Here's how I use it.  My objective with it is to replace that
/something/ in the text file with a new argument.

--8<-------------------------------------------------------->8---
%cat sample.txt 
Lorem ipsum dolor...

<<Release>>=
something
@ 

... sit a met [...]
%
--8<-------------------------------------------------------->8---

Here's how I invoke it:

--8<-------------------------------------------------------->8---
%sh make-release release1 sample.txt 
Lorem ipsum dolor...

<<Release>>=
release1
@ 

... sit a met [...]
--8<-------------------------------------------------------->8---

So far so good.  I decided to try it on longer files and I wanted to see
the change more quickly (without long files scrolling past my terminal),
so I decided to add a /q/ command right after the c commmand.  I
thought---it will make sed quit right after making the change, so I can
see it works as desired and then I remove the /q/ and release it to
production.  But that did not happen.

--8<-------------------------------------------------------->8---
%cat make-release
#!/bin/sh
usage()
{
  printf '%s tag file\n' $0
  exit 1
}
test $# '<' 2 && usage
tag="$1"
shift
sed "/<<Release>>=/ {
 n;
 c\\
$tag
q}" $*
--8<-------------------------------------------------------->8---

I still see the whole file:

--8<-------------------------------------------------------->8---
%sh make-release release1 sample.txt 
Lorem ipsum dolor...

<<Release>>=
release1
@ 

... sit a met [...]
%
--8<-------------------------------------------------------->8---

I failed the exercise I gave myself.  Can you help me to understand why
the q command isn't stopping sed as I thought it would?  I'd like to get
a better intuition.

I've been reading Dale Dougherty and Arnold Robin's ``sed & awk'' book.
If you have any recommended sed-related bibliography, I'd appreciate it,
too.

[toc] | [next] | [standalone]

#25974

On 2024-12-18 2:46 p.m., Salvador Mirzo wrote:
> (*) Summary
> 
> I wrote a sed script that makes a line replacement after it finds the
> right spot.  So far so good.  Then I added quit command after the
> change, but the quit does not seem to take effect---violating my
> expectation.  I'll appreciate any help on understanding what's going on.
[snip]
> So far so good.  I decided to try it on longer files and I wanted to see
> the change more quickly (without long files scrolling past my terminal),
> so I decided to add a /q/ command right after the c commmand.  I
> thought---it will make sed quit right after making the change, so I can
> see it works as desired and then I remove the /q/ and release it to
> production.  But that did not happen.
[snip]
> I failed the exercise I gave myself.  Can you help me to understand why
> the q command isn't stopping sed as I thought it would?  I'd like to get
> a better intuition.

By default sed prints the "pattern space", i.e. all lines in the file.
You can suppress that with the "-n" option to sed.  (In other words, use
"sed -n" instead of plain "sed" in your script.)

The man page for GNU sed 4.9 says about the "q" command:

"Immediately quit the sed script without processing any more input,
except that if auto-print is not disabled the current pattern space will
be printed."

So the behaviour you're seeing without the "-n" option is to be
expected:  pattern space still gets auto-printed after the "q" command.

[toc] | [prev] | [next] | [standalone]

#25975

Salvador Mirzo wrote:

> I failed the exercise I gave myself.  Can you help me to understand why
> the q command isn't stopping sed as I thought it would?  I'd like to get
> a better intuition.

The specification in https://pubs.opengroup.org/onlinepubs/9799919799/
says at the end of the c command "Start the next cycle."
So any commands following it won't be executed.
The rationale does not mention the reason for the behavior specified.

Here, replacing the single-line c command with s/.*/$tag/ would do it.
If you needed a range of lines to be changed, that might become tricky.

[toc] | [prev] | [next] | [standalone]

#25976

Ralf Damaschke <rwspam@gmx.de> writes:

> Salvador Mirzo wrote:
>
>> I failed the exercise I gave myself.  Can you help me to understand why
>> the q command isn't stopping sed as I thought it would?  I'd like to get
>> a better intuition.
>
> The specification in https://pubs.opengroup.org/onlinepubs/9799919799/

That's the home page.  I believe you meant to link the sed page
directly.  When copying URLs from the specification, we need to copy the
framed URL, otherwise we always end up at the home page.  The framed sed
page is at 

  https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

> says at the end of the c command "Start the next cycle."
> So any commands following it won't be executed.
> The rationale does not mention the reason for the behavior specified.

Interesting.  Thanks for mentioning.  I wonder if I understand the
information.  I tried to change a line and then append another.  In both
FreeBSD's and GNU's sed, I the append takes place (and I thought they
would not if they were to obey the specification).

$ cat x.txt
a line
x
more lines
more lines

$ sed '/^x/{c\
hello
a\
hi
}' x.txt
a line
hello
hi
more lines
more lines
$

> Here, replacing the single-line c command with s/.*/$tag/ would do it.
> If you needed a range of lines to be changed, that might become tricky.

I don't need a range of lines to be changed, but I'd like to replace the
string only in the second line of the narrow region of interest.  I
tried your idea and it works, so I guess that way I can be POSIX-compliant.

-- 
Thanks!

[toc] | [prev] | [next] | [standalone]

#25977

Salvador Mirzo wrote:

> Ralf Damaschke <rwspam@gmx.de> writes:
>> The specification in https://pubs.opengroup.org/onlinepubs/9799919799/
> 
> That's the home page.  I believe you meant to link the sed page
> directly.  When copying URLs from the specification, we need to copy the
> framed URL, otherwise we always end up at the home page.  The framed sed
> page is at
> 
>   https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

Actually I considered that. But I felt that the top page might be of more
value since it is easy to find "Shell & Utilities" and "Utilities" in the
frames at the left, whereas the HOME link at the subframe leads to a very
detailed table of content where I would have to use the browser's find
command to locate the specs of other commands.

> I tried to change a line and then append another.  In both
> FreeBSD's and GNU's sed, I the append takes place (and I thought they
> would not if they were to obey the specification).

> $ sed '/^x/{c\
> hello a\
> hi }' x.txt a line hello hi more lines more lines $
> $ sed '/^x/{c\
> hello
> a\
> hi
> }' x.txt

For GNU sed that might be a version issue.
On my system with sed version "sed (GNU sed) 4.9" the copied&pasted
command only prints "hello" for "x" and ignores the append command.

[toc] | [prev] | [next] | [standalone]

#25978

In article <lsjtj8F2r8aU1@mid.individual.net>,
Salvador Mirzo wrote:
...
>> $ sed '/^x/{c\
>> hello a\
>> hi }' x.txt a line hello hi more lines more lines $
>> $ sed '/^x/{c\
>> hello
>> a\
>> hi
>> }' x.txt

Isn't this about the time where we give the caution about "Don't use sed
for anything beyond the s/foo/bar/g stage" ?

Seriously, the above looks like gobbledegook compared to the equivalent in
AWK (or some other normal scripting langugae).  "sed" looks like Intercal
(once you get beyond s/foo/bar/g).

I'm sure that whatever it is that OP is trying to do, it could be easily
translated to (say) AWK and look much nicer.

-- 
The whole aim of practical politics is to keep the populace alarmed (and hence clamorous
to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.

H. L. Mencken

[toc] | [prev] | [next] | [standalone]

#25987

Kenny McCormack schrieb:

> Isn't this about the time where we give the caution about "Don't use sed
> for anything beyond the s/foo/bar/g stage" ?

Simply because you cannot imagine how to use it? No!

[toc] | [prev] | [next] | [standalone]

#25988

On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:
> Kenny McCormack schrieb:
>
>> Isn't this about the time where we give the caution about "Don't use sed
>> for anything beyond the s/foo/bar/g stage" ?
>
> Simply because you cannot imagine how to use it? No!

He explained the "because", in the immediately following text that you snipped:

KMC> Seriously, the above looks like gobbledegook compared to the equivalent in                            
KMC> AWK (or some other normal scripting langugae).  "sed" looks like Intercal                             
KMC> (once you get beyond s/foo/bar/g).                                                                    
                                                                                                      
KMC> I'm sure that whatever it is that OP is trying to do, it could be easily                              
KMC> translated to (say) AWK and look much nicer.  

The reasoning doesn't quite match up with the characterization "can't imagine
how to use it". Kenny need not imagine; he has seen examples of how to
use Sed in ways beyond s/x/y/g, and has the above remarks about that.

Sed is one of the so-called "esolangs" which some people use for puzzling.
For instance, here is a kind of Lisp interpreter written in Sed:

https://github.com/shinh/sedlisp/blob/master/sedlisp.sed

The goal of writing in sed is not to solve the problem, and to communicate with
future users of the program so that they can adapt it to changing needs; the
goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"

Just like the goal of solving a Sudoku isn't to get 9 digits in every row,
colum and box. That's the ostensible goal within the puzzle. The actual goal
of the puzzler is to engage in puzzle solving.

The given text processing problem to be solved in Sed serves a similar purpose
to the 9 digit constraint rules in Sudoku: it just creates the pretext for
entertaining puzzle solving, and is not the actual goal.

People looking for solutions in their production workflow do not want
"hey, look, this can be done in Sed!" type stuff. While people /can/
ramp up on it and easily become proficient, the only ones ever to do so are
going to be engineers looking to waste time on puzzles.

Engineers not looking for puzzing won't ramp up on stuff like this because
it provides no value outside of puzzing. For production work, you need
a language which not only orchestrates the needed computation on the machine,
but also captures the requirements in a way that communicates to people.
Programming languages are a form of documentation!

Nobody wants to write cryptic gobbledygook just for shits and giggles, only to
then have to write an accompanying ream of boring to try to bring it up to the
same communication standard that comes from just writing nothing but code in an
expressive language.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#25989 — sed... (Was: a sed question)

In article <20241220184059.820@kylheku.com>,
Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
...
>
>Sed is one of the so-called "esolangs" which some people use for puzzling.
>For instance, here is a kind of Lisp interpreter written in Sed:
>
>https://github.com/shinh/sedlisp/blob/master/sedlisp.sed
>
>The goal of writing in sed is not to solve the problem, and to communicate with
>future users of the program so that they can adapt it to changing needs; the
>goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"

Exactly.  Well said and well put.

(rest clipped, but should be required reading for everyone)

-- 
He continues to assert that 2 plus 2 equals 4, despite being repeatedly
told otherwise.

[toc] | [prev] | [next] | [standalone]

#25990 — Re: sed... (Was: a sed question)

On 2024-12-21, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20241220184059.820@kylheku.com>,
> Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
> ...
>>
>>Sed is one of the so-called "esolangs" which some people use for puzzling.
>>For instance, here is a kind of Lisp interpreter written in Sed:
>>
>>https://github.com/shinh/sedlisp/blob/master/sedlisp.sed
>>
>>The goal of writing in sed is not to solve the problem, and to communicate with
>>future users of the program so that they can adapt it to changing needs; the
>>goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>>look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"
>
> Exactly.  Well said and well put.
>
> (rest clipped, but should be required reading for everyone)

Sometimes that puzzled out stuff people do in their spare time is really cool!

This just appeared on HackerNews:

https://github.com/izabera/pseudo3d

A raycast first-person maze navigator, written in Bash.

(The code is pretty small and not particularly cryptic.)

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#25994 — Re: sed... (Was: a sed question)

On 21.12.2024 04:57, Kaz Kylheku wrote:
> 
> Sometimes that puzzled out stuff people do in their spare time is really cool!
> 
> This just appeared on HackerNews:
> 
> https://github.com/izabera/pseudo3d
> 
> A raycast first-person maze navigator, written in Bash.

Wasn't there a similar code in Awk mentioned some time ago?

> (The code is pretty small and not particularly cryptic.)

Janis

[toc] | [prev] | [next] | [standalone]

#25998 — Re: sed... (Was: a sed question)

On 21.12.2024 15:38, Janis Papanagnou wrote:
> On 21.12.2024 04:57, Kaz Kylheku wrote:
>>
>> Sometimes that puzzled out stuff people do in their spare time is really cool!
>>
>> This just appeared on HackerNews:
>>
>> https://github.com/izabera/pseudo3d
>>
>> A raycast first-person maze navigator, written in Bash.
> 
> Wasn't there a similar code in Awk mentioned some time ago?

I found it (fps.awk) on my file system; ~650 LOC - too long to post?
(I see it uses some GNU Awk features.)
To support searches for it, it says: #Copyright (c) 2016 Fedor Kalugin

Janis

[toc] | [prev] | [next] | [standalone]

#26005 — Re: sed...

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 21.12.2024 15:38, Janis Papanagnou wrote:
>> On 21.12.2024 04:57, Kaz Kylheku wrote:
>>>
>>> Sometimes that puzzled out stuff people do in their spare time is really cool!
>>>
>>> This just appeared on HackerNews:
>>>
>>> https://github.com/izabera/pseudo3d
>>>
>>> A raycast first-person maze navigator, written in Bash.
>> 
>> Wasn't there a similar code in Awk mentioned some time ago?
>
> I found it (fps.awk) on my file system; ~650 LOC - too long to post?
> (I see it uses some GNU Awk features.)
> To support searches for it, it says: #Copyright (c) 2016 Fedor Kalugin

https://github.com/patsie75/awk-fps

I don't think this is the same thing; there's no copyright and the file
names don't match.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26006 — Re: sed...

On 21.12.2024 23:23, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 21.12.2024 15:38, Janis Papanagnou wrote:
>>> On 21.12.2024 04:57, Kaz Kylheku wrote:
>>>>
>>>> Sometimes that puzzled out stuff people do in their spare time is really cool!
>>>>
>>>> This just appeared on HackerNews:
>>>>
>>>> https://github.com/izabera/pseudo3d
>>>>
>>>> A raycast first-person maze navigator, written in Bash.
>>>
>>> Wasn't there a similar code in Awk mentioned some time ago?
>>
>> I found it (fps.awk) on my file system; ~650 LOC - too long to post?
>> (I see it uses some GNU Awk features.)
>> To support searches for it, it says: #Copyright (c) 2016 Fedor Kalugin
> 
> https://github.com/patsie75/awk-fps

It's something different. - But thanks for the link!

> I don't think this is the same thing; there's no copyright and the file
> names don't match.

I don't know the original filename; I might have changed it on download.

I've put the source version I meant here:  volatile.gridbug.de/fps.awk

Janis

[toc] | [prev] | [next] | [standalone]

#26004 — Re: sed... (Was: a sed question)

In article <20241220184059.820@kylheku.com>,
 Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
>> The goal of writing in sed is not to solve the problem, and to
>> communicate with
>> future users of the program so that they can adapt it to changing needs; the
>> goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>> look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"

Just like APL.
- "can you figure out what this one-line program does?"
- "can you think of a way to do this in fewer characters?"

[toc] | [prev] | [next] | [standalone]

#26025 — Re: sed... (Was: a sed question)

On 2024-12-21, Lars Poulsen <lars@cleo.beagle-ears.com> wrote:
> In article <20241220184059.820@kylheku.com>,
>  Kaz Kylheku  <643-408-1753@kylheku.com> wrote:
>>> The goal of writing in sed is not to solve the problem, and to
>>> communicate with
>>> future users of the program so that they can adapt it to changing needs; the
>>> goal is to puzzle out what it takes to solve it in Sed, and to show: "Hey,
>>> look, I did this in Sed! Isn't it amazing? (And, by extension, aren't I?)"
>
> Just like APL.
> - "can you figure out what this one-line program does?"
> - "can you think of a way to do this in fewer characters?"

It's not quite so easy to casually dismiss APL, because if you look past
the reduction in character syntax, it has a powerful array processing
paradigm that made it unique at the time of its inception. APL programs
are actually short in the number of tokens and operations specified, not
just character count.

Sed is more like BrainF##### in just making things stupidly harder;
it's not a notation for something powerful under the hood.

A sed program won't necessarily be shorter than an Awk one. For instance
certainly not if it has to implement integer addition using regexps on
strings, where the Awk program just does a + b.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#25993

On 21.12.2024 04:09, Kaz Kylheku wrote:
> On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:
>> [...]
> [...]
> 
> People looking for solutions in their production workflow do not want
> "hey, look, this can be done in Sed!" type stuff. While people /can/
> ramp up on it and easily become proficient, the only ones ever to do so are
> going to be engineers looking to waste time on puzzles.

I like your comparison with puzzles, specifically this essence.

Janis

> [...]

[toc] | [prev] | [next] | [standalone]

#26014

Kaz Kylheku wrote:
> On 2024-12-21, Ralf Damaschke <rwspam@gmx.de> wrote:
>> Simply because you cannot imagine how to use it? No!
> 
> He explained the "because", in the immediately following text that you
> snipped:

I don't agree with his explanation.

> KMC> Seriously, the above looks like gobbledegook compared to the
> equivalent in
> KMC> AWK (or some other normal scripting langugae).  "sed" looks like
> Intercal
> KMC> (once you get beyond s/foo/bar/g).

For many people C looks like gobbledegook, too.

> KMC> I'm sure that whatever it is that OP is trying to do, it could be
> easily
> KMC> translated to (say) AWK and look much nicer.

That's probably true. I often prefer awk too, but that is not sufficient
to state "don't use sed for anything beyond the s/foo/bar/g stage". There
have been quite some tasks where I used sed.

[toc] | [prev] | [next] | [standalone]

#25980

On 18.12.2024 20:46, Salvador Mirzo wrote:
> (*) Summary
> 
> I wrote a sed script that makes a line replacement after it finds the
> right spot.  So far so good.  Then I added quit command after the
> change, but the quit does not seem to take effect---violating my
> expectation.  I'll appreciate any help on understanding what's going on.

First (before I forget it) change your string comparison '<' to the
numerical comparison operator '-lt' as in:   test $# -lt 2 && usage
Otherwise, if you get used to using the wrong operator, you may get
subtle errors in future if you continue that habit.

Also note that using  $*  may not work correctly (e.g. depending on
filenames [containing spaces] used). The safe form is a quoted  "$@"

(Then I was tempted to make a similar comment as Kenny. But...)

WRT your question I'd be interested to understand more about the
intention of your original question...

I mean if you don't trust your 'sed' command just pipe it though
'less'; there's no need to change the 'sed' program just for that.

Personally I'd try whether it works (by adding "something" before
and also after the desired place in your sample.txt to be sure the
other occurrences were not changed), and then just call

  sed -e '/<<Release>>=/,+1s/something/sth else/'  sample.txt

to see it working.

Janis

> 
> (*) A detailed description
> 
> I wrote this program:
> 
> --8<-------------------------------------------------------->8---
> %cat make-release
> #!/bin/sh
> usage()
> {
>   printf '%s tag file\n' $0
>   exit 1
> }
> test $# '<' 2 && usage
> tag="$1"
> shift
> sed "/<<Release>>=/ {
>  n;
>  c\\
> $tag
> }" $*
> --8<-------------------------------------------------------->8---
> 
> Here's how I use it.  My objective with it is to replace that
> /something/ in the text file with a new argument.
> 
> --8<-------------------------------------------------------->8---
> %cat sample.txt 
> Lorem ipsum dolor...
> 
> <<Release>>=
> something
> @ 
> 
> ... sit a met [...]
> %
> --8<-------------------------------------------------------->8---
> 
> Here's how I invoke it:
> 
> --8<-------------------------------------------------------->8---
> %sh make-release release1 sample.txt 
> Lorem ipsum dolor...
> 
> <<Release>>=
> release1
> @ 
> 
> ... sit a met [...]
> --8<-------------------------------------------------------->8---
> 
> So far so good.  I decided to try it on longer files and I wanted to see
> the change more quickly (without long files scrolling past my terminal),
> so I decided to add a /q/ command right after the c commmand.  I
> thought---it will make sed quit right after making the change, so I can
> see it works as desired and then I remove the /q/ and release it to
> production.  But that did not happen.
> 
> --8<-------------------------------------------------------->8---
> %cat make-release
> #!/bin/sh
> usage()
> {
>   printf '%s tag file\n' $0
>   exit 1
> }
> test $# '<' 2 && usage
> tag="$1"
> shift
> sed "/<<Release>>=/ {
>  n;
>  c\\
> $tag
> q}" $*
> --8<-------------------------------------------------------->8---
> 
> I still see the whole file:
> 
> --8<-------------------------------------------------------->8---
> %sh make-release release1 sample.txt 
> Lorem ipsum dolor...
> 
> <<Release>>=
> release1
> @ 
> 
> ... sit a met [...]
> %
> --8<-------------------------------------------------------->8---
> 
> I failed the exercise I gave myself.  Can you help me to understand why
> the q command isn't stopping sed as I thought it would?  I'd like to get
> a better intuition.
> 
> I've been reading Dale Dougherty and Arnold Robin's ``sed & awk'' book.
> If you have any recommended sed-related bibliography, I'd appreciate it,
> too.
> 

[toc] | [prev] | [next] | [standalone]

#25981 — Checking for right # of args in a shell script (Was: a sed question)

In article <vk40gi$3g9sm$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>On 18.12.2024 20:46, Salvador Mirzo wrote:
>> (*) Summary
>> 
>> I wrote a sed script that makes a line replacement after it finds the
>> right spot.  So far so good.  Then I added quit command after the
>> change, but the quit does not seem to take effect---violating my
>> expectation.  I'll appreciate any help on understanding what's going on.
>
>First (before I forget it) change your string comparison '<' to the
>numerical comparison operator '-lt' as in:   test $# -lt 2 && usage
>Otherwise, if you get used to using the wrong operator, you may get
>subtle errors in future if you continue that habit.

Agreed, in general, but in practice, the need rarely arises.

The idiomatic way to do this is just:

    [ $# = 2 ] || usage()

Also, when I need to do more complex arg verification, I use bash's [[ ]]
mechanism (Yes, I know OP is using /bin/sh, but there is no reason nowadays
not to use bash).  Say I want there to be 2 or 3 args (no other # is
acceptable and the 2nd arg must be numeric.  Like this:

    [[ $#,$2 =~ ^[23],[0-9]+$ ]] || { echo "Arg error!"; exit; }

-- 
On the subject of racism being depicted in the media, the far right and the far left have
met up in agreement (sort of like how plus infinity meets up with minus infinity).
The far left doesn't want it, because they are afraid it will make people racist.
The far right doesn't want it, because they are afraid it will make people feel bad about being racist.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.unix.shell

csiph-web