[Webkit-unassigned] [Bug 189237] New: Arguments passed to GNU 'sed' by the postprocess header scripts are not accepted.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=189237

            Bug ID: 189237
           Summary: Arguments passed to GNU 'sed' by the postprocess
                    header scripts are not accepted.
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Macintosh
                OS: iOS 10.3
            Status: NEW
          Severity: Trivial
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: biddlebugz at gmail.com

This is more a nit-pick than a bug.

The Mac OS build was failing for me.

There are two places where a sed transformation is applied to headers:

./Source/JavaScriptCore/postprocess-headers.sh @ line 92
./Source/WebKit/mac/postprocess-framework-headers.sh @ line 84

Inspecting the scripts, the intent is to create a backup file with a '.tmp' extension:

  sed -i .tmp -E "${SED_OPTIONS[@]}" "${TARGET_TEMP_DIR}/${HEADER_PATH##*/}" || exit $?

[Note the space between `sed -i` and `.tmp`]

On my system I have 'gnu-sed' installed ahead of the system version and it fails with the following error: 

sed: can't read .tmp: No such file or directory

So the problem is self-inflicted.

Most of the manuals I could find for 'standard' sed specify that the 'backup extension suffix' syntax has the `-i` followed by the suffix without any whitespace.

'/usr/bin/sed' prints usage information that shows it expects the syntax with whitespace:

  >/usr/bin/sed --usage
  /usr/bin/sed: illegal option -- -
  usage: sed script [-Ealn] [-i extension] [file ...]
         sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

Then I tested and the '/usr/bin/sed' version will also accept the 'no-space' syntax. 

Simply removing the space got me past the problem:

  sed -i.tmp -E "${SED_OPTIONS[@]}" "${TARGET_TEMP_DIR}/${HEADER_PATH##*/}" || exit $?

I'm not sure if this worth changing, it's been this way in the codebase for a long time as is. Searching the bugbase didn't show any related complaints.

The entire in-place '-i' option itself is non-standard; it doesn't show in the bare-bones definition: [https://www.unix.com/man-page/posix/1P/sed]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180903/9eefe986/attachment.html>