threads / discuss / 63630

Solaris sed

Subject: Solaris sed

## tl;dr

15 messages between Jun 12, 2025 and Jun 13, 2025.

replies: 14people: 7as markdown or json

Brad Smith· Jun 12, 2025, 03:23 UTC · lore
Building on Solaris I noticed the following two issues with Solaris sed.
     GEN version-def.h
sed: Missing newline at end of file standard input.
     GEN config-list.h
sed: illegal option -- E
Usage:  sed [-n] script [file...]
         sed [-n] [-e script]...[-f script_file]...[file...]
https://github.com/git/git/commit/e1b81f54da80267edee2cb8fd0d0f75f03023019

The second issue being introduced fairly recently. Not sure what would be appropriate fixes. Just pointing them out if someone has an suggestions for fixes.

Collin Funk· Jun 12, 2025, 03:42 UTC · re: Brad Smith · lore

Re: Solaris sed

Hi Brad,
Brad Smith <brad@comstyle.com> writes:
Show 16 quoted lines
> Building on Solaris I noticed the following two issues with Solaris sed.
>
>     GEN version-def.h
> sed: Missing newline at end of file standard input.
>
>     GEN config-list.h
> sed: illegal option -- E
> Usage:  sed [-n] script [file...]
>         sed [-n] [-e script]...[-f script_file]...[file...]
>
>
> https://github.com/git/git/commit/e1b81f54da80267edee2cb8fd0d0f75f03023019
>
> The second issue being introduced fairly recently. Not sure what would be
> appropriate fixes. Just pointing them out if someone has an suggestions for
> fixes.

I noticed these as well, but just ignored them since it seems to build fine.

The first one seems like just a warning? Probably something to do with POSIX defining a "Text File" as "A file that contains characters organized into zero or more lines" where a line is "A sequence of zero or more non- <newline> characters plus a terminating <newline> character."

The second is more tricky. The '-E' option to use EREs was not added to the specification for 'sed' until POSIX.1-2024 [1]. Maybe the script could check for the 'gsed' command? All of the (few) Solaris machines I use will have many GNU programs installed like that.

Collin
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
Brad Smith· Jun 12, 2025, 03:49 UTC · re: Collin Funk · lore

Re: Solaris sed

On 2025-06-11 11:42 p.m., Collin Funk wrote:
Show 28 quoted lines
> Hi Brad,
>
> Brad Smith <brad@comstyle.com> writes:
>
>> Building on Solaris I noticed the following two issues with Solaris sed.
>>
>>      GEN version-def.h
>> sed: Missing newline at end of file standard input.
>>
>>      GEN config-list.h
>> sed: illegal option -- E
>> Usage:  sed [-n] script [file...]
>>          sed [-n] [-e script]...[-f script_file]...[file...]
>>
>>
>> https://github.com/git/git/commit/e1b81f54da80267edee2cb8fd0d0f75f03023019
>>
>> The second issue being introduced fairly recently. Not sure what would be
>> appropriate fixes. Just pointing them out if someone has an suggestions for
>> fixes.
> I noticed these as well, but just ignored them since it seems to build
> fine.
>
> The first one seems like just a warning? Probably something to do with
> POSIX defining a "Text File" as "A file that contains characters
> organized into zero or more lines" where a line is "A sequence of zero
> or more non- <newline> characters plus a terminating <newline>
> character."

It looks as if it is just a warning to me. I wasn't worrying about that one as much as I was the second issue.

> The second is more tricky. The '-E' option to use EREs was not added to
> the specification for 'sed' until POSIX.1-2024 [1]. Maybe the script
> could check for the 'gsed' command? All of the (few) Solaris machines I
> use will have many GNU programs installed like that.

I can't comment on that especially as the build bits support pretty old releases and I have no idea how long Sun / Oracle have been shipping GNU bits like this. I do not believe this has always been a thing.

> Collin
>
> [1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
>
Eli Schwartz· Jun 12, 2025, 04:16 UTC · re: Brad Smith · lore

Re: Solaris sed

On 6/11/25 11:49 PM, Brad Smith wrote:
Show 44 quoted lines
> On 2025-06-11 11:42 p.m., Collin Funk wrote:
>> Hi Brad,
>>
>> Brad Smith <brad@comstyle.com> writes:
>>
>>> Building on Solaris I noticed the following two issues with Solaris sed.
>>>
>>>      GEN version-def.h
>>> sed: Missing newline at end of file standard input.
>>>
>>>      GEN config-list.h
>>> sed: illegal option -- E
>>> Usage:  sed [-n] script [file...]
>>>          sed [-n] [-e script]...[-f script_file]...[file...]
>>>
>>>
>>> https://github.com/git/git/commit/
>>> e1b81f54da80267edee2cb8fd0d0f75f03023019
>>>
>>> The second issue being introduced fairly recently. Not sure what
>>> would be
>>> appropriate fixes. Just pointing them out if someone has an
>>> suggestions for
>>> fixes.
>> I noticed these as well, but just ignored them since it seems to build
>> fine.
>>
>> The first one seems like just a warning? Probably something to do with
>> POSIX defining a "Text File" as "A file that contains characters
>> organized into zero or more lines" where a line is "A sequence of zero
>> or more non- <newline> characters plus a terminating <newline>
>> character."
> It looks as if it is just a warning to me. I wasn't worrying about that
> one as much
> as I was the second issue.
>> The second is more tricky. The '-E' option to use EREs was not added to
>> the specification for 'sed' until POSIX.1-2024 [1]. Maybe the script
>> could check for the 'gsed' command? All of the (few) Solaris machines I
>> use will have many GNU programs installed like that.
> I can't comment on that especially as the build bits support pretty old
> releases and
> I have no idea how long Sun / Oracle have been shipping GNU bits like
> this. I do not
> believe this has always been a thing.

The Solaris box I have a shell on, has gsed installed as a purely optional third-party addon from a third-party package feed. As far as I know, Solaris never did nor plans to ship "GNU bits like this".

Of course, the Git project *could* declare users must first build GNU sed, then build Git. Or only build on boxes where the admin is a GNU enthusiast. But that option seems unlikely and unattractive...

-- 
Eli Schwartz
Collin Funk· Jun 12, 2025, 04:25 UTC · re: Eli Schwartz · lore

Re: Solaris sed

Eli Schwartz <eschwartz@gentoo.org> writes:
Show 14 quoted lines
>>> The second is more tricky. The '-E' option to use EREs was not added to
>>> the specification for 'sed' until POSIX.1-2024 [1]. Maybe the script
>>> could check for the 'gsed' command? All of the (few) Solaris machines I
>>> use will have many GNU programs installed like that.
>> I can't comment on that especially as the build bits support pretty old
>> releases and
>> I have no idea how long Sun / Oracle have been shipping GNU bits like
>> this. I do not
>> believe this has always been a thing.
>
>
> The Solaris box I have a shell on, has gsed installed as a purely
> optional third-party addon from a third-party package feed. As far as I
> know, Solaris never did nor plans to ship "GNU bits like this".

Yes, sorry for not being clear. It is not installed by default. On the compile farm machines I have access to it is always installed by the maintainer. Or on VMs I use, I always download it. I figured that is pretty common.

> Of course, the Git project *could* declare users must first build GNU
> sed, then build Git. Or only build on boxes where the admin is a GNU
> enthusiast. But that option seems unlikely and unattractive...

Perhaps I am too mean to Solaris... Their 'date' command made me give a similar recommendation before. Anyways, Junio wrote a patch that avoids us forcing GNU tools on them.

Collin
Brad Smith· Jun 12, 2025, 04:26 UTC · re: Eli Schwartz · lore

Re: Solaris sed

On 2025-06-12 12:16 a.m., Eli Schwartz wrote:
Show 53 quoted lines
> On 6/11/25 11:49 PM, Brad Smith wrote:
>> On 2025-06-11 11:42 p.m., Collin Funk wrote:
>>> Hi Brad,
>>>
>>> Brad Smith <brad@comstyle.com> writes:
>>>
>>>> Building on Solaris I noticed the following two issues with Solaris sed.
>>>>
>>>>       GEN version-def.h
>>>> sed: Missing newline at end of file standard input.
>>>>
>>>>       GEN config-list.h
>>>> sed: illegal option -- E
>>>> Usage:  sed [-n] script [file...]
>>>>           sed [-n] [-e script]...[-f script_file]...[file...]
>>>>
>>>>
>>>> https://github.com/git/git/commit/
>>>> e1b81f54da80267edee2cb8fd0d0f75f03023019
>>>>
>>>> The second issue being introduced fairly recently. Not sure what
>>>> would be
>>>> appropriate fixes. Just pointing them out if someone has an
>>>> suggestions for
>>>> fixes.
>>> I noticed these as well, but just ignored them since it seems to build
>>> fine.
>>>
>>> The first one seems like just a warning? Probably something to do with
>>> POSIX defining a "Text File" as "A file that contains characters
>>> organized into zero or more lines" where a line is "A sequence of zero
>>> or more non- <newline> characters plus a terminating <newline>
>>> character."
>> It looks as if it is just a warning to me. I wasn't worrying about that
>> one as much
>> as I was the second issue.
>>> The second is more tricky. The '-E' option to use EREs was not added to
>>> the specification for 'sed' until POSIX.1-2024 [1]. Maybe the script
>>> could check for the 'gsed' command? All of the (few) Solaris machines I
>>> use will have many GNU programs installed like that.
>> I can't comment on that especially as the build bits support pretty old
>> releases and
>> I have no idea how long Sun / Oracle have been shipping GNU bits like
>> this. I do not
>> believe this has always been a thing.
>
> The Solaris box I have a shell on, has gsed installed as a purely
> optional third-party addon from a third-party package feed. As far as I
> know, Solaris never did nor plans to ship "GNU bits like this".
>
> Of course, the Git project *could* declare users must first build GNU
> sed, then build Git. Or only build on boxes where the admin is a GNU
> enthusiast. But that option seems unlikely and unattractive...

To clarify what I meant. Solaris 11 from the looks of it includes GNU sed with the base OS. That was not the case with 10 and older.

The documentation for 11.4 for example mentions both versions of sed.

https://docs.oracle.com/cd/E88353_01/html/E37839/sed-1.html https://docs.oracle.com/cd/E88353_01/html/E37839/sed-1g.html

Junio C Hamano· Jun 12, 2025, 04:03 UTC · re: Brad Smith · lore

Re: Solaris sed

Brad Smith <brad@comstyle.com> writes:
> Building on Solaris I noticed the following two issues with Solaris sed.
>
>     GEN version-def.h
> sed: Missing newline at end of file standard input.

Perhaps it is this input line it is complaining about. sed works on text files, and a file that ends in incomplete line was not quite text.

-REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
+REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
 	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
 	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
 	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
>     GEN config-list.h
> sed: illegal option -- E
> Usage:  sed [-n] script [file...]
>         sed [-n] [-e script]...[-f script_file]...[file...]

This is a bit trickier but should be doable. It does not like the -E option to use ERE (as opposed to BRE) for pattern matching used in generate-configlist.sh script.

	sed -E '
	/^`?[a-zA-Z].*\..*`?::$/ {
	/deprecated/d;
	s/::$//;
	s/`//g;
	s/^.*$/	"&",/;
	p;};
	d'

I think the only problematic one is the first address, whose BRE equivalent I think is

	/^`\{0,1\}[a-zA-Z].*\..*`\{0,1\}::$/

In practice, I suspect \{0,1\} is unnecessarily strict and using something looser like

	/^`*[a-zA-Z].*\..*`*::$/

may be sufficient. Replace the address expression associated with the {editing command} and drop "-E", and use "-e" for readability, perhaps?

Totally untested patch follows.
 GIT-VERSION-GEN        | 2 +-
 generate-configlist.sh | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)
diff --git c/GIT-VERSION-GEN w/GIT-VERSION-GEN
index 208e91a17f..de989657fb 100755
--- c/GIT-VERSION-GEN
+++ w/GIT-VERSION-GEN
@@ -82,7 +82,7 @@ read GIT_MAJOR_VERSION GIT_MINOR_VERSION GIT_MICRO_VERSION GIT_PATCH_LEVEL trail
 $(echo "$GIT_VERSION" 0 0 0 0 | tr '.a-zA-Z-' ' ')
 EOF
 
-REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
+REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
 	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
 	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
 	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
diff --git c/generate-configlist.sh w/generate-configlist.sh
index 9d2ad6165d..75c39ade20 100755
--- c/generate-configlist.sh
+++ w/generate-configlist.sh
@@ -13,16 +13,16 @@ print_config_list () {
 	cat <<EOF
 static const char *config_name_list[] = {
 EOF
-	sed -E '
-/^`?[a-zA-Z].*\..*`?::$/ {
+	sed -e '
+	/^`*[a-zA-Z].*\..*`*::$/ {
 	/deprecated/d;
 	s/::$//;
 	s/`//g;
 	s/^.*$/	"&",/;
 	p;};
-d' \
+	d' \
 	    "$SOURCE_DIR"/Documentation/*config.adoc \
-	    "$SOURCE_DIR"/Documentation/config/*.adoc|
+	    "$SOURCE_DIR"/Documentation/config/*.adoc |
 	sort
 	cat <<EOF
 	NULL,
Brad Smith· Jun 12, 2025, 04:13 UTC · re: Junio C Hamano · lore

Re: Solaris sed

On 2025-06-12 12:03 a.m., Junio C Hamano wrote:
Show 91 quoted lines
> Brad Smith <brad@comstyle.com> writes:
>
>> Building on Solaris I noticed the following two issues with Solaris sed.
>>
>>      GEN version-def.h
>> sed: Missing newline at end of file standard input.
> Perhaps it is this input line it is complaining about.  sed works on
> text files, and a file that ends in incomplete line was not quite
> text.
>
> -REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
> +REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
>   	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
>   	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
>   	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
>
>>      GEN config-list.h
>> sed: illegal option -- E
>> Usage:  sed [-n] script [file...]
>>          sed [-n] [-e script]...[-f script_file]...[file...]
> This is a bit trickier but should be doable.  It does not like the
> -E option to use ERE (as opposed to BRE) for pattern matching used
> in generate-configlist.sh script.
>
> 	sed -E '
> 	/^`?[a-zA-Z].*\..*`?::$/ {
> 	/deprecated/d;
> 	s/::$//;
> 	s/`//g;
> 	s/^.*$/	"&",/;
> 	p;};
> 	d'
>
> I think the only problematic one is the first address, whose BRE
> equivalent I think is
>
> 	/^`\{0,1\}[a-zA-Z].*\..*`\{0,1\}::$/
>
> In practice, I suspect \{0,1\} is unnecessarily strict and using
> something looser like
>
> 	/^`*[a-zA-Z].*\..*`*::$/
>
> may be sufficient.  Replace the address expression associated with
> the {editing command} and drop "-E", and use "-e" for readability,
> perhaps?
>
> Totally untested patch follows.
>
>   GIT-VERSION-GEN        | 2 +-
>   generate-configlist.sh | 8 ++++----
>   2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git c/GIT-VERSION-GEN w/GIT-VERSION-GEN
> index 208e91a17f..de989657fb 100755
> --- c/GIT-VERSION-GEN
> +++ w/GIT-VERSION-GEN
> @@ -82,7 +82,7 @@ read GIT_MAJOR_VERSION GIT_MINOR_VERSION GIT_MICRO_VERSION GIT_PATCH_LEVEL trail
>   $(echo "$GIT_VERSION" 0 0 0 0 | tr '.a-zA-Z-' ' ')
>   EOF
>   
> -REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
> +REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
>   	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
>   	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
>   	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
> diff --git c/generate-configlist.sh w/generate-configlist.sh
> index 9d2ad6165d..75c39ade20 100755
> --- c/generate-configlist.sh
> +++ w/generate-configlist.sh
> @@ -13,16 +13,16 @@ print_config_list () {
>   	cat <<EOF
>   static const char *config_name_list[] = {
>   EOF
> -	sed -E '
> -/^`?[a-zA-Z].*\..*`?::$/ {
> +	sed -e '
> +	/^`*[a-zA-Z].*\..*`*::$/ {
>   	/deprecated/d;
>   	s/::$//;
>   	s/`//g;
>   	s/^.*$/	"&",/;
>   	p;};
> -d' \
> +	d' \
>   	    "$SOURCE_DIR"/Documentation/*config.adoc \
> -	    "$SOURCE_DIR"/Documentation/config/*.adoc|
> +	    "$SOURCE_DIR"/Documentation/config/*.adoc |
>   	sort
>   	cat <<EOF
>   	NULL,
No errors or warnings after this is applied.
Collin Funk· Jun 12, 2025, 04:19 UTC · re: Brad Smith · lore

Re: Solaris sed

Brad Smith <brad@comstyle.com> writes:
Show 47 quoted lines
>> Totally untested patch follows.
>>
>>   GIT-VERSION-GEN        | 2 +-
>>   generate-configlist.sh | 8 ++++----
>>   2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git c/GIT-VERSION-GEN w/GIT-VERSION-GEN
>> index 208e91a17f..de989657fb 100755
>> --- c/GIT-VERSION-GEN
>> +++ w/GIT-VERSION-GEN
>> @@ -82,7 +82,7 @@ read GIT_MAJOR_VERSION GIT_MINOR_VERSION GIT_MICRO_VERSION GIT_PATCH_LEVEL trail
>>   $(echo "$GIT_VERSION" 0 0 0 0 | tr '.a-zA-Z-' ' ')
>>   EOF
>>   -REPLACED=$(printf "%s" "$INPUT" | sed -e
>> "s|@GIT_VERSION@|$GIT_VERSION|" \
>> +REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
>>   	-e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
>>   	-e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
>>   	-e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
>> diff --git c/generate-configlist.sh w/generate-configlist.sh
>> index 9d2ad6165d..75c39ade20 100755
>> --- c/generate-configlist.sh
>> +++ w/generate-configlist.sh
>> @@ -13,16 +13,16 @@ print_config_list () {
>>   	cat <<EOF
>>   static const char *config_name_list[] = {
>>   EOF
>> -	sed -E '
>> -/^`?[a-zA-Z].*\..*`?::$/ {
>> +	sed -e '
>> +	/^`*[a-zA-Z].*\..*`*::$/ {
>>   	/deprecated/d;
>>   	s/::$//;
>>   	s/`//g;
>>   	s/^.*$/	"&",/;
>>   	p;};
>> -d' \
>> +	d' \
>>   	    "$SOURCE_DIR"/Documentation/*config.adoc \
>> -	    "$SOURCE_DIR"/Documentation/config/*.adoc|
>> +	    "$SOURCE_DIR"/Documentation/config/*.adoc |
>>   	sort
>>   	cat <<EOF
>>   	NULL,
>
>
> No errors or warnings after this is applied.
Likewise.

I checked on my Linux machine and both files are the same before and after the patch. Before the patch on Solaris 10, the following is generated:

    /* Automatically generated by generate-configlist.sh */
    
    
    static const char *config_name_list[] = {
            NULL,
    };
After the patch the output on Solaris is the same as on Linux.
So the patch is perfect.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
Collin
Jean-Noël AVILA· Jun 13, 2025, 20:13 UTC · re: Collin Funk · lore

Re: Solaris sed

On Thursday, 12 June 2025 06:19:35 CEST Collin Funk wrote:
> Brad Smith <brad@comstyle.com> writes:
Show 22 quoted lines
> > No errors or warnings after this is applied.
> 
> Likewise.
> 
> I checked on my Linux machine and both files are the same before and
> after the patch. Before the patch on Solaris 10, the following is
> generated:
> 
>     /* Automatically generated by generate-configlist.sh */
> 
> 
>     static const char *config_name_list[] = {
>             NULL,
>     };
> 
> After the patch the output on Solaris is the same as on Linux.
> 
> So the patch is perfect.
> 
> Reviewed-by: Collin Funk <collin.funk1@gmail.com>
> 
> Collin
Hello, 

Would it be possible to set up some kind of CI to check for compatibility with such systems. This is the second time I introduced regressions without even knowing it, and it would be really great to catch them before borking a release process.

Thanks,
JN
Eric Sunshine· Jun 13, 2025, 20:23 UTC · re: Jean-Noël AVILA · lore

Re: Solaris sed

On Fri, Jun 13, 2025 at 4:15 PM Jean-Noël AVILA <jn.avila@free.fr> wrote:
> Would it be possible to set up some kind of CI to check for compatibility with
> such systems. This is the second time I introduced regressions without even
> knowing it, and it would be really great to catch them before borking a
> release process.

Had this been in a test script, it would have been caught by t/check-non-portable-shell.sh. We may want to apply the check to build-related scripts, as well. For instance, it would have caught the -E problem:

    % ./t/check-non-portable-shell.pl generate-*.sh
    generate-configlist.sh:16: error: sed option not portable (use
only -n, -e, -f): sed -E '
    %

You can, of course, run check-non-portable-shell.pl manually after editing a script, but perhaps this check could be enabled by a (hopefully) minor tweak to the main Git Makefile?

Collin Funk· Jun 13, 2025, 20:30 UTC · re: Jean-Noël AVILA · lore

Re: Solaris sed

Jean-Noël AVILA <jn.avila@free.fr> writes:
> Would it be possible to set up some kind of CI to check for compatibility with 
> such systems. This is the second time I introduced regressions without even 
> knowing it, and it would be really great to catch them before borking a 
> release process.

I'm sure that Solaris packagers are used to patching stuff like this. I wouldn't feel guilty about it. It is difficult to remember all these portability quirks.

With GitHub actions you can add Oracle Solaris and OmniOS (based on illumos, which was based on OpenSolaris) using vmactions [1]. That might help catch some stuff.

In this case, the build still works even with the broken sed commands. Not sure if the tests would have caught it though.

Collin
[1] https://github.com/vmactions
Eric Sunshine· Jun 12, 2025, 05:50 UTC · re: Junio C Hamano · lore

Re: Solaris sed

On Thu, Jun 12, 2025 at 12:05 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> Brad Smith <brad@comstyle.com> writes:
> > Building on Solaris I noticed the following two issues with Solaris sed.
> >     GEN version-def.h
> > sed: Missing newline at end of file standard input.
>
> Perhaps it is this input line it is complaining about.  sed works on
> text files, and a file that ends in incomplete line was not quite
> text.
>
> -REPLACED=$(printf "%s" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
> +REPLACED=$(printf "%s\n" "$INPUT" | sed -e "s|@GIT_VERSION@|$GIT_VERSION|" \
>         -e "s|@GIT_MAJOR_VERSION@|$GIT_MAJOR_VERSION|" \
>         -e "s|@GIT_MINOR_VERSION@|$GIT_MINOR_VERSION|" \
>         -e "s|@GIT_MICRO_VERSION@|$GIT_MICRO_VERSION|" \
It's curious that this is using:
    printf "%s" "$foo"`
in the first place. Had it used the simpler:
    echo "$foo"
this sort of problem (forgetting the "\n") would never have occurred.

In fact, it seems that f6a2efdc9b (GIT-VERSION-GEN: allow running without input and output files, 2025-01-22), which introduced this problem, also introduced a few similar cases in which the `printf "%s\n"` idiom was employed when a simple `echo` would have sufficed.

Paul Smith· Jun 12, 2025, 13:35 UTC · re: Eric Sunshine · lore

Re: Solaris sed

On Thu, 2025-06-12 at 01:50 -0400, Eric Sunshine wrote:
Show 5 quoted lines
> Had it used the simpler:
> 
>     echo "$foo"
> 
> this sort of problem (forgetting the "\n") would never have occurred.

Just be aware that echo is not well-standardized: many versions of echo accept extra options or treat certain chars specially. So, printf (which IS well-standardized) is always safer unless you are 100% sure that the text on the echo command line is simple: cannot start with a "-", doesn't contain special chars like backslash, etc.

For portability I (personally) always prefer printf unless I know exactly what the text contains (like showing a static string).

Eric Sunshine· Jun 12, 2025, 16:40 UTC · re: Paul Smith · lore

Re: Solaris sed

On Thu, Jun 12, 2025 at 9:44 AM Paul Smith <paul@mad-scientist.net> wrote:
Show 15 quoted lines
> On Thu, 2025-06-12 at 01:50 -0400, Eric Sunshine wrote:
> > Had it used the simpler:
> >
> >     echo "$foo"
> >
> > this sort of problem (forgetting the "\n") would never have occurred.
>
> Just be aware that echo is not well-standardized: many versions of echo
> accept extra options or treat certain chars specially.  So, printf
> (which IS well-standardized) is always safer unless you are 100% sure
> that the text on the echo command line is simple: cannot start with a
> "-", doesn't contain special chars like backslash, etc.
>
> For portability I (personally) always prefer printf unless I know
> exactly what the text contains (like showing a static string).

Yup, you're right. I always do the same when I can't trust the argument to be `echo`-safe, but apparently I wasn't thinking of that case when I wrote the email. Thanks for the dose of sanity.

← back to recent threads