should `string` be modified to not append a newline to its final line of output?

[krader1961]

While working on issue #2855 I noticed that we can't simply do clear | string replace \e\[3J "" because the string replace will append an unwanted newline. The solution in this case is simple enough: just use a command substitution to eat the newline. But it got me wondering if perhaps we should only append a newline to all but the final line of output unless reading from stdin and the final line of input ended with a newline. Note that doing something like string replace x y axxb | some_command would still send a newline terminated string to some_command.

This change would make mistakes involving piping arbitrary strings through string less likely. On the other hand it's an exception to the general rule that string writes "lines" (defined as ending with a newline).

[ridiculousfish]

Good question. What are the uses for string that don't involve a command substitution? I don't follow how you would have liked to use this for clear

[krader1961]

In this instance, and some others I've seen, it is more natural to use clear | string replace \e\[3J "" rather than echo -n (clear | string replace \e\[3J ""). This is obviously a niche situation but it bit @faho when he changed the \cL binding to use the first solution and will undoubtedly bite other people.

[zanchey]

I think this is a duplicate of #3082.

[krader1961]

Indeed, it is a dup of #3082, @zanchey. And another example of how the current behavior surprises people. There is one subtle difference, however, that may not be clear from my poorly worded problem description. I am not proposing that we change the behavior when iterating over CLI arguments. In that case all arguments, even if there is only one, would still be written with a terminating newline. I'm only proposing changing how input from stdin is handled. In that case string would include a terminating newline iff the input ended with a newline. That keeps constructs like

echo -n hello | string replace l L

from surprisingly appending a newline that wasn't present in the input. If we decide not to make that change in behavior then the documentation should be augmented to make the current behavior abundantly clear.

[krader1961]

Also, regardless of whether we change the behavior I think we should clarify the documentation.

[krader1961]

@faho and I had a conversation on Gitter earlier today which referenced this issue. The result was the proposal the string should also have a -z flag to complement read -z, etc. That would cause it to split input from stdin on null bytes rather than newlines. It would also cause its output to be null separated. In which case we'll want fish command substitution output parsing to split on null characters if any are present else newlines. Something it should probably do regardless so that you can do things like set files (find . -print0).

However, I think that is orthogonal to this proposal. Which is that if the input from stdin does not contain a terminating newline, and either no null characters or the proposed -z flag is not used, then the output should not be terminated with a null or newline character. That way you can safely transform strings containing neither without adding either one. For example, echo -n hello | string replace -a l L would not add a newline to the string written to stdout.

[luolong]

I use command line quite often to copy path to a CLI tool to the system clipboard so that I can paste it in to some editor. Something along the lines of:

> which rustfmt | pbcopy

Sometimes, this causes problems when the paste destination is inside a json string for example. The result is annoying, as I always have to delete the newline after pasting. Having a simple enough option to remove trailing line feed from the string being copied to clipboard would be one less of those little paper cuts to worry about...

[ThomasAH]

+1 for changing/fixing this. I just updated our company's internal documentation for fish and removed most of the issues solved in fish 3.x compared to older versions, and this is the only issue that survived the upgrade to 3.x

[ridiculousfish]

@ThomasAH can you describe the particular problem you're facing, and what would address it for you? Thanks!

[ThomasAH]

@ThomasAH can you describe the particular problem you're facing, and what would address it for you? Thanks!

When working with existing files that do not end with a newline, using "string replace" adds a newline. Example:

echo -n foo > x
cat x
Output: foo⏎                                                                                                                                                        
string replace foo bar < x > y
cat y
Output: bar

One place where I encountered this was when working with MAC addresses and wanted to replace dashes with colons to be used in a config file. Here my workaround is to use an additional variable:

echo -n "00-11-22-33-44-55" > mac
set MAC (cat mac)
echo -n "$MAC"
Output: 00-11-22-33-44-55⏎
set MAC2 (string replace -a - : $MAC)
echo -n "$MAC2"
Output: 00:11:22:33:44:55⏎

But having to use workarounds isn't nice.

string replace should not add newlines by itself.
If the behavior shouldn't be changed this late in the life of frish, at least an option to prevent it is important.
Maybe use -N/--no-newline like with string repeat?

[ridiculousfish]

Ok, let's try to fix this for 3.2. Hopefully we can just stop emitting them and won't need a new option.

[krobelus]

I think it's safe to stop adding a newline if the input to string replace is piped or redirected.

Not sure about when inputs are given on the commandline. I'd leave that case as is.

[faho]

Okay, I'm going to punt this from the 3.2.0 milestone.