Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

syntax: line continuation characters inside a string #873

Closed
ColemanTom opened this issue Jun 6, 2022 · 2 comments · Fixed by #896
Closed

syntax: line continuation characters inside a string #873

ColemanTom opened this issue Jun 6, 2022 · 2 comments · Fixed by #896

Comments

@ColemanTom
Copy link

I have just noticed that recently shfmt has changed expectations about strings. My guess is it relates to 4556b2f

I was wondering if this was expected/desired behaviour?

Originally this was fine for shfmt (at least with v3.4.2)

read -r pt ypt mpt <<< \
    "$(date -d "${DATE} -$DIFFERENCE hours" \
        "+%YmdH %Y %m")"

Now shfmt wants to change it to

read -r pt ypt mpt <<< "\
$(date -d "${DATE} -$DIFFERENCE hours" \
    "+%YmdH %Y %m")"

My personal view is the original was more readable. Otherwise changing it to something like what I have below is possibly clearer still (at least for python devs).

read -r pt ypt mpt <<< "$(
    "$(date -d "${DATE} -$DIFFERENCE hours" \
        "+%YmdH %Y %m"
)"
@mvdan mvdan changed the title Line continuation characters inside a string syntax: line continuation characters inside a string Jun 14, 2022
@mvdan
Copy link
Owner

mvdan commented Jun 14, 2022

Thanks for raising this; I'm fairly sure this is an unintended regression.

mvdan added a commit that referenced this issue Jul 3, 2022
@mvdan
syntax: allow escaped newlines to precede unquoted words again
a66ddcd 
As part of fixing #832, to prevent breaking some programs with escaped
newlines, I went slightly too far with the tightening of the rules.
The input script

	foo <<< \
		"bar baz"

would now reformat as

	foo <<< "\
	bar baz"

The script is functionally the same, but it looks objectively worse.
It is harmless to allow a leading escaped newline when not quoted,
as it doesn't break any programs nor result in worse formatting.

Note that the script

	foo=\
	bar

will still reformat as `foo=bar`, so in that case we keep the recent
change in behavior. That case is different, as we can't safely indent
the continuing line - thus we can't produce good formatting unless we
join the lines.

While here, remove incomplete code that I had left commented out in the
last patch, and then forgot to remove before merging.

Fixes #873.
@mvdan mvdan mentioned this issue Jul 3, 2022
Merged
@mvdan
Copy link
Owner

mvdan commented Jul 3, 2022

Err, I actually wrote a complete fix for this three weeks ago, and I was sure I had already merged it to master. Somehow, I kept it in a local branch and completely forgot about it :) See #896.

@mvdan mvdan closed this as completed in #896 Jul 4, 2022
mvdan added a commit that referenced this issue Jul 4, 2022
@mvdan
syntax: allow escaped newlines to precede unquoted words again
4723414 
As part of fixing #832, to prevent breaking some programs with escaped
newlines, I went slightly too far with the tightening of the rules.
The input script

	foo <<< \
		"bar baz"

would now reformat as

	foo <<< "\
	bar baz"

The script is functionally the same, but it looks objectively worse.
It is harmless to allow a leading escaped newline when not quoted,
as it doesn't break any programs nor result in worse formatting.

Note that the script

	foo=\
	bar

will still reformat as `foo=bar`, so in that case we keep the recent
change in behavior. That case is different, as we can't safely indent
the continuing line - thus we can't produce good formatting unless we
join the lines.

While here, remove incomplete code that I had left commented out in the
last patch, and then forgot to remove before merging.

Fixes #873.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

syntax: allow escaped newlines to precede unquoted words again mvdan/sh
2 participants
@mvdan @ColemanTom