Features/F18MorePortableInterpreters
From FedoraProject
< Features(Difference between revisions)
(initial version) |
(Add some reasons not to do this) |
||
| Line 84: | Line 84: | ||
== Comments and Discussion == | == Comments and Discussion == | ||
* See [[Talk:Features/F18MorePortableInterpreters]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --> | * See [[Talk:Features/F18MorePortableInterpreters]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page --> | ||
| − | + | * 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. | ||
[[Category:FeaturePageIncomplete]] | [[Category:FeaturePageIncomplete]] | ||
Latest revision as of 22:09, 25 October 2011
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.
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.
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
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed
Contents |
[edit] More Portable Interpreters
[edit] Summary
Use a portable version of the interpreters call in scripts.
[edit] Owner
- Name: Michal Piotrowski [[User:| Harald Hoyer]] (?)
- Email: <michal@eventhorizon.pl>
[edit] Current status
- Targeted release: Fedora 18
- Last updated: (DATE)
- Percentage of completion: 0%
[edit] 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
[edit] Benefit to Fedora
[edit] Scope
[edit] How To Test
[edit] User Experience
[edit] Dependencies
[edit] Contingency Plan
[edit] Documentation
[edit] Release Notes
[edit] 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.
