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

Groups > comp.editors > #106924 > unrolled thread

Vim - serial numbering of text items

Back to article view | Back to comp.editors

Contents

  Vim - serial numbering of text items Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-07 11:24 +0200
    Re: Vim - serial numbering of text items Eli the Bearded <*@eli.users.panix.com> - 2026-07-07 21:55 +0000
      Re: Vim - serial numbering of text items Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-08 02:50 +0000
        Re: Vim - serial numbering of text items Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-08 07:02 +0200
      Re: Vim - serial numbering of text items Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-08 07:34 +0200
        Re: Vim - serial numbering of text items Eli the Bearded <*@eli.users.panix.com> - 2026-07-08 06:05 +0000
    Re: Vim - serial numbering of text items Eric Pozharski <apple.universe@posteo.net> - 2026-07-08 17:22 +0000
      Re: Vim - serial numbering of text items Eli the Bearded <*@eli.users.panix.com> - 2026-07-08 21:17 +0000
        Re: Vim - serial numbering of text items Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-09 03:36 +0200
          Re: Vim - serial numbering of text items Eric Pozharski <apple.universe@posteo.net> - 2026-07-09 19:02 +0000
          Re: Vim - serial numbering of text items Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-07-10 02:15 +0300
            Re: Vim - serial numbering of text items Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-10 08:32 +0200
            Re: Vim - serial numbering of text items Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-10 06:45 +0000
              Re: Vim - serial numbering of text items Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-07-11 03:23 +0300
                Re: Vim - serial numbering of text items Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-11 22:04 +0000
        Re: Vim - serial numbering of text items Eric Pozharski <apple.universe@posteo.net> - 2026-07-09 18:55 +0000

#106924 — Vim - serial numbering of text items

Is there in Vim a built-in simple (=non-scripting) way to automatically
number text entities by serial numbers; e.g. with an input of either

Lorem ipsum
Lorem ipsum
Lorem ipsum

or

Lorem # ipsum
Lorem # ipsum
Lorem # ipsum

to create (for example)

Lorem 1 ipsum
Lorem 2 ipsum
Lorem 3 ipsum

I've thought about something like Ctrl-v to mark a column and then have
some command to create the serial numbers, but while I can to

   Ctrl-v !seq 1 3

that command will, unfortunately, replace the whole lines' contents by
the number sequence (and not only the marked column).

I can also work around it by a couple manual commands but, as said, I'm
looking for something simple, more straightforward.

For the second input sample above, with the '#' mark as placeholder, I
could also resort to an external program to do the serial numbering.[*]
So, generally, first inserting the hash marks with  <Ctrl-v> I # <Esc>
(in case they are all in one column) then running the external script.
(But that would be not better than other workarounds or Vim-scripting.)

Janis

[*] E.g. with Awk:  sub(/#/,++c)

[toc] | [next] | [standalone]

#106925

In comp.editors, Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
> Is there in Vim a built-in simple (=non-scripting) way to automatically
> number text entities by serial numbers; e.g. with an input of either
> 
> Lorem ipsum
> Lorem ipsum
> Lorem ipsum
> 
> or
> 
> Lorem # ipsum
> Lorem # ipsum
> Lorem # ipsum
> 
> to create (for example)
> 
> Lorem 1 ipsum
> Lorem 2 ipsum
> Lorem 3 ipsum

"Simple"? Probably not. It can be done. I've written tail recusive
macros to do things like this, grabbing a number to replace it on the
next line and then incrementing with ctrl-a, but recursive macros are
fraught with special cases to consider.

> I've thought about something like Ctrl-v to mark a column and then have
> some command to create the serial numbers, but while I can to
> 
>    Ctrl-v !seq 1 3
> 
> that command will, unfortunately, replace the whole lines' contents by
> the number sequence (and not only the marked column).

If you !nl instead you can number the lines and then move the number.
Using Gnu nl:

  !nl -bp'\#' -w1 -s: -d ''

Number lines with a # in them, use minimum number width of 1, put a :
after the number, disable page break number rules.

Then move numbers with something like:

:g/^[1-9][0-9]*:.*#/ s,^\([0-9]*\):\([^#]*\)#,\2\1,

> I can also work around it by a couple manual commands but, as said, I'm
> looking for something simple, more straightforward.

I would use a recursive macro for one large file, always formatted the
same, the two part nl and move for vi instead of vim or when formatting
makes a macro awkward, and a separate script (probably in perl) for a
regular operation.

> [*] E.g. with Awk:  sub(/#/,++c)

Not everything needs to be done by the editor.

Elijah
------
has never touched vimscript but that may have a way to do it

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

#106926

On Tue, 7 Jul 2026 21:55:02 -0000 (UTC), Eli the Bearded wrote:

> "Simple"? Probably not. It can be done. I've written tail recusive
> macros to do things like this, grabbing a number to replace it on
> the next line and then incrementing with ctrl-a, but recursive
> macros are fraught with special cases to consider.

Isn’t there some version of Vim that uses Lua as its extension
language?

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

#106927

On 2026-07-08 04:50, Lawrence D’Oliveiro wrote:
> On Tue, 7 Jul 2026 21:55:02 -0000 (UTC), Eli the Bearded wrote:
> 
>> "Simple"? Probably not. It can be done. I've written tail recusive
>> macros to do things like this, grabbing a number to replace it on
>> the next line and then incrementing with ctrl-a, but recursive
>> macros are fraught with special cases to consider.
> 
> Isn’t there some version of Vim that uses Lua as its extension
> language?

I seem to recall that one of the features of the _neovim_ project
replaced the vim scripting language by lua. (Neovim is not a Vim
version, though.)

But note that Lua isn't necessary in Vim, one can use its native
scripting language. - Though my request was ideally looking for a
native support of that feature since I try to avoid externalities
(plugins, macros, external commands) as far as possible; I've no
plugins, only few macros that I rarely use, and only occasionally
use external commands on text sections.

Janis

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

#106928

On 2026-07-07 23:55, Eli the Bearded wrote:
> In comp.editors, Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>> Is there in Vim a built-in simple (=non-scripting) way to automatically
>> number text entities by serial numbers; e.g. with an input of either
>>
>> [...]
> 
> "Simple"? Probably not. It can be done. I've written tail recusive
> macros to do things like this, grabbing a number to replace it on the
> next line and then incrementing with ctrl-a, but recursive macros are
> fraught with special cases to consider.

Ctrl-a was actually what I was recently using manually; insert a column
of '1', mark column, then move cursor down one by one and type Ctrl-a;
works well when there's no side-effect on lines below the marked area.

> 
>> I've thought about something like Ctrl-v to mark a column and then have
>> some command to create the serial numbers, but while I can to
>>
>>     Ctrl-v !seq 1 3
>>
>> that command will, unfortunately, replace the whole lines' contents by
>> the number sequence (and not only the marked column).
> 
> If you !nl instead you can number the lines and then move the number.
> Using Gnu nl:
> 
>    !nl -bp'\#' -w1 -s: -d ''

I've occasionally used external line numbering with a block-cut/paste
to the desired location. Less elaborated (more simplistic) than your
approach but a sensible workaround anyway.

> 
> Number lines with a # in them, use minimum number width of 1, put a :
> after the number, disable page break number rules.
> 
> Then move numbers with something like:
> 
> :g/^[1-9][0-9]*:.*#/ s,^\([0-9]*\):\([^#]*\)#,\2\1,

And at some point it's obviously time for a macro.

> 
>> I can also work around it by a couple manual commands but, as said, I'm
>> looking for something simple, more straightforward.
> 
> I would use a recursive macro for one large file, always formatted the
> same, the two part nl and move for vi instead of vim or when formatting
> makes a macro awkward, and a separate script (probably in perl) for a
> regular operation.

(I didn't understand your preference for Vi here, "instead of Vim".)

> 
>> [*] E.g. with Awk:  sub(/#/,++c)
> 
> Not everything needs to be done by the editor.

Right. - Since there's no simple builtin mechanism it might indeed be
worth to use such an external awk-primitive (perl in your case); mark
the region and call  !sn  (with a one-line awk script 'sn').

> 
> Elijah
> ------
> has never touched vimscript but that may have a way to do it

I'd suspect so. But since I've also not touched vimscript myself, and
want to keep that independence, I'll continue to abstain. :-)

Janis

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

#106929

In comp.editors, Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
> On 2026-07-07 23:55, Eli the Bearded wrote:
>> I would use a recursive macro for one large file, always formatted the
>> same, the two part nl and move for vi instead of vim or when formatting
>> makes a macro awkward, and a separate script (probably in perl) for a
>> regular operation.
> (I didn't understand your preference for Vi here, "instead of Vim".)

Sometimes the vi I have is not vim. I learned vi on Bill Joy vi, but I
found vim less buggy and switched to that as my preferred vi. But I log
into a lot of machines and not all will have vim installed. So, like
when I write shell scripts for sh instead of bash, I keep in mind the
non-improved ways to do things.

Elijah
------
actually very, very rarely uses bash with bash-isms, but ksh-isms sometimes

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

#106930

with <112igko$2n4ld$1@dont-email.me> Janis Papanagnou wrote:

> Is there in Vim a built-in simple (=non-scripting) way to
> automatically number text entities by serial numbers; e.g. with an
> input of either
*SKIP* [  4 lines   1 level deep]

> Lorem # ipsum
> Lorem # ipsum
> Lorem # ipsum
>
> to create (for example)
>
> Lorem 1 ipsum
> Lorem 2 ipsum
> Lorem 3 ipsum
>
*SKIP* [  5 lines   1 level deep]
>
> I can also work around it by a couple manual commands but, as said, I'm
> looking for something simple, more straightforward.

	:%s, # ,\=" " . line(".") . " "

You owe me 10min.

p.s.  Also, vimBASIC isa bitch.

*CUT* [  7 lines   1 level deep]

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

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

#106931

In comp.editors, Eric Pozharski  <apple.universe@posteo.net> wrote:
> 	:%s, # ,\=" " . line(".") . " "
> 
> You owe me 10min.
> 
> p.s.  Also, vimBASIC isa bitch.

What if # should start at 1 even if the first "Lorem # ipsum" does not
appear until line 20?

Elijah
------
did not know you could trigger scripting from a substitute command

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

#106932

On 2026-07-08 23:17, Eli the Bearded wrote:
> In comp.editors, Eric Pozharski  <apple.universe@posteo.net> wrote:
>> 	:%s, # ,\=" " . line(".") . " "
>>
>> You owe me 10min.

???

>>
>> p.s.  Also, vimBASIC isa bitch.

???

> 
> What if # should start at 1 even if the first "Lorem # ipsum" does not
> appear until line 20?

Indeed - that's a crucial restriction! (And replacing the '%' by a
range e.g. '<,'> also doesn't fix it.) I'd suppose you might be able
to use a static variable instead of 'line()', but I don't intend to
explore Vim's scripting (which I wanted to avoid in the first place).


Meanwhile, since the external command approach was so easy, and the
external command so trivially short, I slightly extended my original
Awk code - sub(/#/,++c) - and have now

   { while (match ($0, /#+/))
       sub (/#+/, sprintf ("%0*d", RLENGTH, ++c))
     print
   }

with the additional properties to change the #-markers also if they
appear multiply on a line, and to be simply able to create leading
zeroes as in

Lorem ## ipsum
Lorem # ipsum ### xyz
Lorem # ipsum # # quit

Lorem 01 ipsum
Lorem 2 ipsum 003 xyz
Lorem 4 ipsum 5 6 quit


> Elijah
> ------
> did not know you could trigger scripting from a substitute command

Likewise. :-)

Janis

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

#106934

with <112mtut$2n4lc$2@dont-email.me> Janis Papanagnou wrote:
> On 2026-07-08 23:17, Eli the Bearded wrote:
>> In comp.editors, Eric Pozharski  <apple.universe@posteo.net> wrote:

>>> 	:%s, # ,\=" " . line(".") . " "
>>> You owe me 10min.
> ???

Time spent digging through help.

>>> p.s.  Also, vimBASIC isa bitch.
> ???

	:h sub-replace-special

I'd just spotted it.  During grepping.  Because peripheral vision.  I
don't think I could find this otherwise:

	:h sub-replace-expression

*CUT* [ 26 lines   2 levels deep]

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

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

#106935

Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
writes:

> Meanwhile, since the external command approach was
> so  easy, and  the external  command so  trivially
> short, I slightly extended  my original Awk code -
> sub(/#/,++c) - and have now

        What follows is not a new answer to the OP's
  original question,  just some  random curiosities.
  May I first note that the approach of piping to an
  external command is not a hack nor a kludge, but a
  core idea  of using a UNIX  computing environment.
  I personally do enjoy it,  very much, and it's why
  an ed-like editor, or at most classic vi, is all I
  usually need to do  all my programming and writing
  work.  UNIX is the IDE.  In this specific use case
  I do think piping to an awk script is a reasonable
  and elegant solution.  In vim,  all you need is to
  mark the  lines where your  # is (I use  `V', then
  select all the lines), and then:

        :'<,'>!awk 'sub(/\#/,++c)'

        In ed or vi, you  can of course use register
  marks instead of a  selection, 'a,'b would be your
  range for example, instead of '<,'>.  I also enjoy
  putting such commands into little shell scripts in
  a directory in my home folder, and then adding the
  directory to the $PATH of my editors using wrapper
  shell functions, or aliases.  For example:

        ~/.edit/nl

        #!/bin/sh
        # replace the string passed
        # as arg1 with counter numbers.
        awk "sub(/$1/,++c)"

  then:

        chmod +x ~/.edit/nl

  then use a  shell alias to call  your editor, with
  the added PATH directory, possibly putting this in
  your ~/.bashrc file:

        alias vi='PATH="$HOME/.edit/:$PATH" vi'

  And now, in vi, you can just run:

        :'<,'>!nl '\#'
  or
        :'<,'>!nl NUM

  replacing # or  NUM with numbers.  As  long as you
  stick  with POSIX  tools,  then  your custom  edit
  scripts are going to be very portable, and no need
  to worry about updates or management or complexity
  of dozens of vim scripts and plugins.  POSIX tools
  tend to be  very stable over time, you  might go a
  decade before a minor breaking change happens here
  or there.  And to have  them on another machine is
  a simple matter of scp for the .edit directory, or
  even just  typing the commands in  yourself if you
  don't need them frequently.  I have little scripts
  like this  for all kinds of  tasks, like centering
  text (shell's printf is usually pretty useful), or
  marking tasks in my to-do list with various status
  markers  (little sed  scripts), various  insertion
  scripts for putting in separators or IDs or links,
  I even have some tiny C programs, used in the same
  way, for example to  align the content of multiple
  lines to some common  part that match some regular
  expression; to align some  lines to the equal sign
  for variable assignments, you do:

        :'<,'>!align =

        Emacs has a feature I enjoy, where you start
  recording a macro using F3, and then each time you
  press F3 again you add a macro step to increment a
  counter, and print its value at the current cursor
  position.  The counter is persistent between macro
  runs in the same  session, so solving your problem
  above is trivial in  Emacs, without even needing a
  placeholder character like # or such.  Just F3, go
  to the place  you want the number,  F3 again, then
  F4 to finish recording, Then  M-100 C-x C-e to run
  it 100  times for  example, and thus  generate 100
  line numbers.  I've seen a few places where such a
  feature would have made things easier, when I used
  vim here and there.

  Just some thoughts,
  Happy editing, friends~


Best Regards,
Lumin Etherlight

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

#106936

On 2026-07-10 01:15, Lumin Etherlight wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
> writes:
> 
>> Meanwhile, since the external command approach was
>> so  easy, and  the external  command so  trivially
>> short, I slightly extended  my original Awk code -
>> sub(/#/,++c) - and have now
> 
>          What follows is not a new answer to the OP's
>    original question,  just some  random curiosities.
>    May I first note that the approach of piping to an
>    external command is not a hack nor a kludge, but a
>    core idea  of using a UNIX  computing environment.

Yes.

>    I personally do enjoy it,  very much, and it's why
>    an ed-like editor, or at most classic vi, is all I
>    usually need to do  all my programming and writing
>    work.  UNIX is the IDE.  In this specific use case
>    I do think piping to an awk script is a reasonable
>    and elegant solution. 

A core point of my original request is that, while the '!'
mechanism is standard, my own tools (like the awk scripts)
are _non-standard_! - That's the reason why I try to avoid
that and prefer Vim built-in solutions to externalities,
be it my own or, worse, third party external tools.

(In my personal environment I have tons of useful scripts
but when I change the working environment these scripts
will not be available!)

>   [...]  For example:
> 
>          ~/.edit/nl
> 
>          #!/bin/sh
>          # replace the string passed
>          # as arg1 with counter numbers.
>          awk "sub(/$1/,++c)"

Actually I didn't need to use arbitrary characters as
placeholders (in practice I see no advantage to allow
other characters; YMMV). *If* it would be necessary I
could always do a substitution, say,  :<range>s/@/#/g
beforehand. For awk programs I also need no additional
shell as interpreter and my pure awk scripts are simply
like this

    #!/bin/awk -f
    sub(/#/,++c)

and directly usable without environmental changes and
complications (as illustrated below).

> 
>    then:
> 
>          chmod +x ~/.edit/nl
> 
>    then use a  shell alias to call  your editor, with
>    the added PATH directory, possibly putting this in
>    your ~/.bashrc file:
> 
>          alias vi='PATH="$HOME/.edit/:$PATH" vi'

That's all organizational ballast I don't need and avoid
if unnecessary.[*]

At this point I want to remind, and don't want to get me
wrong, that the original question was formulated exactly
as it was because I wanted something most simple without
(or with fewest possible) assumptions or environmental
changes. As a 40+ years long Unix user I'm well aware what
you can do with the Unix tool-chest ("IDE" as you called
it). It's not about what you *can* all do; we know that.
It's about minimizing dependencies and minimum impact.

> 
>    And now, in vi, you can just run:
> 
>          :'<,'>!nl '\#'
>    or
>          :'<,'>!nl NUM
> 
>    replacing # or  NUM with numbers.  As  long as you
>    stick  with POSIX  tools,  then  your custom  edit
>    scripts are going to be very portable, and no need

(Your suggestion is using non-standard .bashrc, mind. No
biggie, though, since you can also use POSIX sh rc file.)

In case of non-standard setups I'd prefer ksh functions
and FPATH (instead of aliases and local PATH changes).

>    to worry about updates or management or complexity
>    of dozens of vim scripts and plugins.  POSIX tools
>    tend to be  very stable over time, you  might go a
>    decade before a minor breaking change happens here
>    or there.  And to have  them on another machine is
>    a simple matter of scp for the .edit directory, or

You obviously have some specific working environments in
mind where you have full control over the environment.
That's fine. And privately, at home, I have that control.

But, over the decades of my professional work, that had
been only rarely the case; usually you just have what
the IT management allows within the respective policies.

>    even just  typing the commands in  yourself if you
>    don't need them frequently. 

And that's what makes it a non-desirable approach, and
my seeking for a "most simple" way to tackle that.

>    I have little scripts [...]

Yes, and I'm sure most of us Unix folks have lots of
such useful home-brew (non-standard) scripts.

$ ls ~/bin | wc -l
229

> 
>          Emacs has a feature I enjoy, [...]

I'm not interested in Emacs. - But I'm curious why you
are actually using two very different powerful editors.

> 
>    Just some thoughts,

Thanks.

Janis

[*] I'd like to also note that I usually don't need or
use aliases. While my preinstalled .bashrc is full of
this crap my .kshrc contains just one line  set -o vi .
I'm typically using shell functions, which are much
more flexible and have less restrictions than aliases.

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

#106937

On Fri, 10 Jul 2026 02:15:33 +0300, Lumin Etherlight wrote:

> May I first note that the approach of piping to an external command
> is not a hack nor a kludge, but a core idea of using a UNIX
> computing environment. I personally do enjoy it, very much, and it's
> why an ed-like editor, or at most classic vi, is all I usually need
> to do all my programming and writing work. UNIX is the IDE.

True enough. But there is a right way and a wrong way to do it.

The wrong way is to spawn a shell which then executes a command
string. This requires the command string to have any shell specials
properly escaped, which is a complication you can really do without,
and is often mishandled by lazy programmers.

The right way is to spawn the external command directly, and feed it
an array of command-line arguments, that don’t need any escaping of
shell specials, because there is no shell intermediary involved.

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

#106938

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On Fri, 10 Jul 2026 02:15:33 +0300, Lumin Etherlight wrote:
>
>> May I first  note that the approach  of piping to
>> an external command  is not a hack  nor a kludge,
>> but  a  core  idea  of  using  a  UNIX  computing
>> environment.   I  personally  do enjoy  it,  very
>> much, and it's why an  ed-like editor, or at most
>> classic vi,  is all I  usually need to do  all my
>> programming and writing work. UNIX is the IDE.
>
> True enough. But there is a right way and a wrong way to do it.
>
> The wrong way is to spawn a shell which then executes a command
> string. This requires the command string to have any shell specials
> properly escaped, which is a complication you can really do without,
> and is often mishandled by lazy programmers.
>
> The right way is to spawn the external command directly, and feed it
> an array of command-line arguments, that don’t need any escaping of
> shell specials, because there is no shell intermediary involved.

        Why is it the wrong way?  I understand there
  are caveats to it,  but there are also advantages.
  I prefer the spawning  of an intermediary shell in
  such cases, as it allows me to use shell features,
  such as various shell expansions, especially shell
  variables, plus allowing  easy redirect of content
  to temporary files, or reading and filtering stuff
  from other files into  my current file, and piping
  the text from one command  to another.  I use such
  things all the time, multiple times a day.  I also
  don't handle any escaping in the code of the tools
  I build to work in  this pattern, but instead make
  it clear that  a shell is being  spawned here, and
  the responsibility of any escaping is on the user.
  Of course escaping is rarely an issue, because the
  actual content of the file  is never passed to any
  sub-commands as  an argument, but is  always piped
  around as standard input and output, thus requires
  no escaping.   What requires escaping is  only the
  arguments passed into the command by the user, and
  that is no different from using a normal shell.  I
  do support  the spawning  of the  external command
  directly if the feature  is /abstracted/ away, and
  the user has no idea the shell will be there.  For
  example, you provide a search and replace feature,
  which uses an  external command internally.  Users
  don't really care about the implementation details
  and just want to replace stuff.  In that case, you
  should of course not  surprise them by spawning an
  intermediate shell that would crash out with weird
  errors if their replacement text has a dollar sign
  or what not.  But in cases where the feature being
  advertised is specifically "you  can use any shell
  commands to do whatever you want", then I think it
  is fair for the user  to expect having the various
  shell features they're used to.  Personally, I use
  wordexp(3) to add POSIX  shell word expansion even
  to some features that don't even spawn a shell; as
  I said above, I  find those expansions very useful
  when building workflows that integrate UNIX tools.
  Being able to  do an :e wireguard-user{0..9}.conf,
  or a :w ${CURRENT_FILE}.bak  can be real handy, as
  some minor examples.

  Apologies if I missed your point somehow though :)


Best Regards,
Lumin Etherlight

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

#106939

On Sat, 11 Jul 2026 03:23:53 +0300, Lumin Etherlight wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> The wrong way is to spawn a shell which then executes a command
>> string. This requires the command string to have any shell specials
>> properly escaped, which is a complication you can really do
>> without, and is often mishandled by lazy programmers.
>>
>> The right way is to spawn the external command directly, and feed
>> it an array of command-line arguments, that don’t need any escaping
>> of shell specials, because there is no shell intermediary involved.
>
> Why is it the wrong way? I understand there are caveats to it, but
> there are also advantages. I prefer the spawning of an intermediary
> shell in such cases, as it allows me to use shell features, such as
> various shell expansions, especially shell variables, plus allowing
> easy redirect of content to temporary files, or reading and
> filtering stuff from other files into my current file, and piping
> the text from one command to another.

If you’re writing a program, most of this can be done more robustly
within the program, rather than in an external shell.

> [rest of wall of text deleted]

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

#106933

with <eli$2607081717@qaz.wtf> Eli the Bearded wrote:
> In comp.editors, Eric Pozharski  <apple.universe@posteo.net> wrote:

>> 	:%s, # ,\=" " . line(".") . " "
>> 
>> You owe me 10min.
*SKIP* [  1 line   0 level deep]
> What if # should start at 1 even if the first "Lorem # ipsum" does not
> appear until line 20?

Adopt to your context.  Go wild.

*CUT* [  3 lines   1 level deep]

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [standalone]

Back to top | Article view | comp.editors

csiph-web