remove space from default ifs

[TobyGoodwin]

Since the last release, there's been — by rc standards — a lot of activity. Probably more user visible changes than in the previous quarter century! I'm planning to call the next release 2.0 to reflect this.

There's one more change I'm intending to slip in: remove space from the default value of ifs. One of the delights of using rc is that it handles “spacey” filenames (those that contain spaces) effortlessly... right up to the moment where you use the backquote operator.

Removing space from default ifs will mean that beginning users can write things like

for (f in `{ls | shuf}) { ... }

and have it Just Work.

Does anyone have any strong opinions about this proposal?

[CasperVector]

I for one do not quite like this:

• Filenames can also contain newlines and tabs.
• I, from time to time, write code like the following, which would be broken badly:

  
  #!/bin/rc -e

mopts=noexec,nosuid,nodev mount -n -t tmpfs -o $mopts',mode=0755,size=10M' cgroup_root /sys/fs/cgroup mkdir -m 1777 /dev/mqueue mount -n -t mqueue -o $mopts mqueue /dev/mqueue

for (args in ((){echo}){cat /proc/cgroups}) { if (args=`{echo $args}; ~ $args(3) 1) { name=$args(1) mkdir /sys/fs/cgroup/$name mount -n -t cgroup -o $mopts,$name $name /sys/fs/cgroup/$name } }

for (args in \ 'pstore /sys/fs/pstore' \ 'securityfs /sys/kernel/security' \ ) { args=`{echo $args} mount -n -t $args(1) -o $mopts $args(1) $args(2) }

* As shown above, writing

((){echo}){ ... }

or

nl=(){echo} ... ($nl){ ... } # if used multiple times

seems quite sufficient to me...

[borkovic]

The value of ifs is a part of rc's 25 year old API! Whoever needed ifs without the space has written their script accordingly. Let's not break the scripts that work today. I vote for ifs to remain unchanged.

[xyb3rt]

I too think that this should have been changed 25 years ago. Doing so now only creates a bigger problem: backward incompatibility.

What about adding the special syntax

``{}

to the double backtick operator--with no temporary ifs list--as a shortcut for newline-only backquote substition?

[rakitzis]

I have to agree -- changing this would break old scripts in unpredictable ways.

[TobyGoodwin]

OK, that seems like a pretty firm consensus against the change. In this non-democracy, @rakitzis gets n votes. I'm not sure of the value of n (or even if it's finite)... it's probably best if we avoid finding out 😀

Nevertheless, I have given this quite a lot of thought. So let me muster some of my arguments, and answer your points as best I can.

• 25 years ago, filenames didn't contain spaces. Today they do.

• rc is the shell that handles spacey filenames¹. If we have any interest at all in promoting its wider use, that's a really good Unique Selling Point.

¹ Unless you use backquotes. If you want backquotes and spacey filenames, first you need to know about the double-backquote operator, then you have to figure out how to supply it with an argument that contains a single newline.

• As I mentioned, I'm inclined to call the next release 2.0 because there's a lot of new stuff in it. (Yes, it's mainly backwards compatible, mostly giving meaning to syntax that was previously forbidden. We do have two new builtins, continue and flag which will of course mask same-named programs on your path.) If we don't change this now, we never will.

• Of course I am aware that filenames, under Unix at least, can contain any character except \0. But in the real everyday world, the chance of hitting a filename containing a tab or newline is ~0, whereas the chance of hitting a filename containing a space is ~1.

• Any script that depends on the value of ifs should set it. There will be those that don't, and we should avoid breaking them for no reason.

[TobyGoodwin]

Assuming we leave ifs alone, I still think it would be nice to make it easier to handle spacey filenames in backquotes. I think @muennich 's suggestion is ingenious, but I suspect it might break the parser, and I dislike special cases.

Also ingenious is CasperVector 's

``(``(){echo}){ ... }

I've never seen that before, and I don't think I would ever have thought of it! By the way, you can make it shorter like this:

`` ``()echo { ... }

or even

````x echo{ ... }

Suggestion

How about binding $nl to \n at shell startup? (... if we inherit it with no value, to be certain we're not breaking anything)

[xyb3rt]

I’m pretty sure, that my suggestion does not break the parser. I can open a pull request in case you are interested to try it out.

[xyb3rt]

Also, if you never overwrite ifs in your scripts you can use $ifs(3) to get a newline.

[borkovic]

I quite like the idea of initializing $nl at shell startup. Maybe $tab as well.

[CasperVector]

I also consider setting $nl and $tab to be a cleanest way: minimal intrusiveness, and virtually no additional complexity in the implementation.

[rakitzis]

I don't want my pronouncements to be so heavy.. if anything it's great that rc is getting tidied up in many small ways, but I also think it's great if compatibility is maintained to whatever extent possible.

If binding $nl and $tab works for everyone that sounds like a good suggestion. At the very least $nl is unambiguous and takes its name from the ASCII(7) chart.

[TobyGoodwin]

That last comment got my inner hobgoblin wanting to use the ASCII name for tab too. But I had to look it up (not a good sign!) and it turns out to be ht (horizontal tab), which I have heard before, but it certainly doesn't spring to mind. So I ignored the hobgoblin and went with $nl and $tab in commit 79fcb6d

(Mention of hobgoblins is a reference is to the well-known Ralph Waldo Emerson quote: A foolish consistency is the hobgoblin of little minds.)