Features/F18MorePortableInterpreters

From FedoraProject

< Features
Revision as of 22:09, 25 October 2011 by Toshio (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Important.png
Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.
Important.png
Set a Page Watch
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
Note.png
All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed



Contents

More Portable Interpreters

Summary

Use a portable version of the interpreters call in scripts.

Owner

  • Email: <michal@eventhorizon.pl>

Current status

  • Targeted release: Fedora 18
  • Last updated: (DATE)
  • Percentage of completion: 0%


Detailed Description

Traditionally a lot of scripts uses

\#!/bin/sh

to invoke the interpreter.

Feature https://fedoraproject.org/wiki/Features/UsrMove changes the traditional file system layout. Scripts should not rely on a hard coded pathes. Should be used more portable interpreter call.

\#!/usr/bin/env sh

Benefit to Fedora

Scope

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

Comments and Discussion

    1. It's unnecessary because the FHS specifies that /bin/sh must exist (the UsrMove feature doesn't interfere with this as the FHS allows symlinks and UsrMove creates compat symlinks).
    2. Using env would allow a new way to inject a different version of the shell into scripts which admins will need to consider when auditing their system security.
    3. In the event that someone has a different version of sh in their path for their own use, you don't want that sh to be used with scripts intended to run with the system sh.
    4. If the purpose is to protect against changes to where binaries fall in the filesystem path, you're just moving the problem around. Instead of relying on /bin/sh existing, we now rely on /usr/bin/env existing. Additionally, these are shell scripts. Unless we rewrite the scripts themselves to change all constructs like /sbin/ifconfig | /bin/grep eth* to ifconfig | grep eth* at the same time, we aren't really protecting against path changes.
    5. Using env is unnecessary overhead, not just for running systems but also for packagers to rewrite scripts and produce Fedora-specific patches for.