From Fedora Project Wiki
< Features
More Portable Interpreters
Summary
Use a portable version of the interpreters call in scripts.
Owner
- Name: Michal Piotrowski [[User:| Harald Hoyer]] (?)
- 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
- See Talk:Features/F18MorePortableInterpreters
- This doesn't seem like a good idea:
- 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).
- 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.
- 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.
- 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.
- Using env is unnecessary overhead, not just for running systems but also for packagers to rewrite scripts and produce Fedora-specific patches for.