Slashdot Mirror
A Real Bourne Shell for Linux?
"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash. If bash is invoked with sh as its name (argv[0]) then its supposed to act like Bourne - but that just doesnt happen (for example: export FOO=bar is *not* valid Bourne shell syntax, you must say FOO=bar; export FOO)
Do you think that the startup scripts for most distributions would break because, even though they say #!/bin/sh at the top, they REALLY mean #!/bin/bash?
Given that there is no real Bourne shell for Linux, and that bash has an exhorbitant file size. Quoting bash's man page, here: '...it's too big and too slow' for something that is to be used as the defacto-standard shell for scripting, do you think its a worthy venture to set out to write a small, tight, pure Bourne shell?
*asbestos disclaimer*: This has nothing to with Bash as an interactive user shell and has nothing to do with a holy war over who's favorite shell is better than whomever's."
While doing a small bit of research on this question, I noted there was another Bourn-compatible shell out there called "ash", yet it's billed as doing "some things better and some things worse than bash". Does anyone use it, and find it better than bash for their shell scripting needs?
gnome is definitly going on the rise, with more and more *NIX's making it their default GUI in next releases ...
I'd rather see bash on HP/UX, etc. Why should we take a giant leap backward for their sake?
- Download FreeBSD source.
- cd
/usr/src/bin/sh; make; make install
AFAIK the BSD Bourne shell is more or less the same as the real Bourne shell."The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
http://groups.google.com/groups?q=Real+Bourne+Shel l+for+Linux&hl=en&client=googlet&rnum=2&selm=7icci f%246lb%243%40remarQ.com
---
http://slashdot.org/moderation.shtml
Starting your scripts with #!/bin/bash shows that you live in a Linux-centric world. No other OS puts bash under /bin. Since there's normally a link from bash to sh, it really makes sense for compatibility reasons to use #!/bin/sh. Of course, if you use bash-specific features in your scripts, your scripts won't be portable anyway and it doesn't really matter, I suppose.
You had me at "dicks fuck assholes".
Why couldn't you just write a small script that chooses what shell to use at the beginning?
Say the following:
File 1: Shell script to determine what *nix you are running
File 2: Bourne shell script
File 3: bash shell script
File 1 determines whether to use Bourne shell script of bash shel script and passes it onto decided shell.
Just a thought... hope I could be helpful!
-theKGB 8)
Eric... You suck...
~% apt-cache show ash /bin/sh
/bin/sh (because it executes scripts
Package: ash
Priority: optional
Section: shells
Installed-Size: 180
Maintainer: Herbert Xu <herbert@debian.org>
Architecture: i386
Version: 0.3.8-29
Pre-Depends: libc6 (>= 2.2.4-2)
Filename: pool/main/a/ash/ash_0.3.8-29_i386.deb
Size: 70564
MD5sum: a9ec33985be6e3a4c350ef19d377c43a
Description: NetBSD
"ash" is a POSIX compliant shell that is much smaller than "bash".
We take advantage of that by making it the shell on the installation
root floppy, where space is at a premium.
.
It can be usefully installed as
somewhat faster than "bash"), or as the default shell either of root
or of a second user with a userid of 0 (because it depends on fewer
libraries, and is therefore less likely to be affected by an upgrade
problem or a disk failure). It is also useful for checking that a
script uses only POSIX syntax.
.
"bash" is a better shell for most users, since it has some nice
features absent from "ash", and is a required part of the system.
You are looking for a solution to a problem that does not exist.
bash is backward compatable to sh. Period.
Yes, you can do things in bash you can't do in sh, but not vice-versa.
If you write your scripts for stock Bourne, they will run fine under bash.
... make? make install? some other shell that doesnt have such ambiguity? like csh? or tcsh?
hash bang slash bin slash bash
Basically, Slackware uses ash for development for the exact reasons you're looking for a Bourne-compatible shell.
Have fun.
"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash." /bin/sh is not bash, and all 'bashisms' are removed from distribution's scripts - it's all plain /bin/sh.
:)
You haven't seen Polished Linux Distribution. PLD's
(Plus, PLD is fully IPV6 ready
:wq
Many would. However, note that POSIX requires /bin/sh to be a POSIX shell, whose specs are derived mostly from the Korn Shell - so ksh is a valid POSIX shell, as is Bash, modulo a few features. Plain-vanilla Bourne shell is not.
AIX has the same dilemma: to be POSIX-compliant they have /bin/sh -> ksh and /bin/bsh is the real Bourne. HP-UX 11 has /bin/sh distinct from ksh, but it too allows things like 'export FOO=BAR'. I don't know if a real Bourne shell exists on HP-UX.
For a POSIX shell without the bash overhead, use ash, which is distributed with many (most?) Linux distributions. ash is the NetBSD /bin/sh, and at least on Debian the installation gives you the /bin/sh symlink option as well. Let me tell you, ash is much faster than bash in the autoconf-generated-configure "benchmark".
Since many Debian people use ash for /bin/sh, packages regularly have bugs filed -- and fixed -- vis-a-vis #!/bin/sh vs. #!/bin/bash. I don't know how careful other distros are about this sort of thing. Note that even many Debian scripts would fail if you found a real Bourne shell for /bin/sh rather than a POSIX-compliant shell.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Do with it what you will.
::= SEQUENCE {
--Anonymous Coward
Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems
April, 2000
Abstract
Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for user logon and to create an access token. The access token is used by the system to enforce access checking when attempting to reference objects. This document describes the structure of the Windows 2000 specific authorization data that is carried in that field.
Top-Level PAC Structure
The PAC is generated by the KDC under the following conditions:
"during an AS request that has been validated with pre-authentication
"during a TGS request when the client has no PAC and the target is a service in the domain or a ticket granting service (referral ticket).
The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket. Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.
The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is made up of several layers. The outer structure, contained directly in the authorization data, is as follows. The top-level structure is the PACTYPE structure:
typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef unsigned long64 ULONG64;
typedef unsigned char UCHAR;
typedef struct _PACTYPE {
ULONG cBuffers;
ULONG Version;
PAC_INFO_BUFFER Buffers[1];
} PACTYPE;
The fields are defined as follows:
cBuffers - contains the number of entries in the array Buffers
Version - this is version zero
Buffers - contains a conformant array of PAC_INFO_BUFFER structures
The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
typedef struct _PAC_INFO_BUFFER {
ULONG ulType;
ULONG cbBufferSize;
ULONG64 Offset;
} PAC_INFO_BUFFER;
Type fields are defined as follows:
ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the following, which are explained further below:
#define PAC_LOGON_INFO 1
#define PAC_CREDENTIAL_TYPE 2
#define PAC_SERVER_CHECKSUM 6
#define PAC_PRIVSVR_CHECKSUM 7
#define PAC_CLIENT_INFO_TYPE 10
Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer types or complex structures) it is a little-endian format data structure.
PAC Credential Information
PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.
typedef struct _KERB_VALIDATION_INFO {
FILETIME LogonTime;
FILETIME LogoffTime;
FILETIME KickOffTime;
FILETIME PasswordLastSet;
FILETIME PasswordCanChange;
FILETIME PasswordMustChange;
UNICODE_STRING EffectiveName;
UNICODE_STRING FullName;
UNICODE_STRING LogonScript;
UNICODE_STRING ProfilePath;
UNICODE_STRING HomeDirectory;
UNICODE_STRING HomeDirectoryDrive;
USHORT LogonCount;
USHORT BadPasswordCount;
ULONG UserId;
ULONG PrimaryGroupId;
ULONG GroupCount;
[size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
ULONG UserFlags;
ULONG Reserved[4];
UNICODE_STRING LogonServer;
UNICODE_STRING LogonDomainName;
PSID LogonDomainId;
ULONG Reserved1[2];
ULONG UserAccountControl;
ULONG Reserved3[7];
ULONG SidCount;
[size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
PSID ResourceGroupDomainSid;
ULONG ResourceGroupCount;
[size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
} KERB_VALIDATION_INFO;
The fields are defined as follows:
LogonTime - the time the client last logged on.
LogoffTime - the time at which the clients logon session should expire. If the logon session should not expire, this field should be set to (0x7fffffff,0xffffffff).
KickOffTime - the time at which the server should forcibly logoff the client. If the client should not be forced off, this field should be set to (0x7fffffff,0xffffffff). The ticket end time is a replacement for the
KickOffTime. The service ticket lifetime will never be longer than the KickOffTime for a user. PasswordLastSet - the time the clients password was last set. If it was never set, this field is zero.
PasswordCanChange - the time at which the clients password is allowed to change. If there is no restriction on when the client may change its password, this field should be set to the time of the logon.
PasswordMustChange - the time at which the clients password expires. If it doesnt expire, this field is set to (0x7fffffff,0xffffffff).
EffectiveName - This field contains the clients Windows 2000 UserName, stored in the Active Directory in the SamAccountName property. This field is optional. If left blank the length, maxlength and buffer are all zero.
FullName - this field contains the friendly name of the client, which is used only for display purpose and not security purposes. This field is optional. If left blank the length, maxlength and buffer are all zero.
LogonScript - This field contains the path to the clients logon script. This field is optional. If left blank the length, maxlength and buffer are all zero.
ProfilePath - This field contains the path to the clients profile. This field is optional. If left blank the length, maxlength and buffer are all zero.
HomeDirectory - This field contains the path to the clients home directory. It may be either a local path name or a UNC path name. This field is optional. If left blank the length, maxlength and buffer are all zero.
HomeDirectoryDrive - This field is only used if the clients home directory is a UNC path name. In that case, the share on the remote file server is mapped to the local drive letter specified by this field. This field is optional. If left blank the length, maxlength and buffer are all zero.
LogonCount - This field contains the count of how many times the client is currently logged on. This statistic is not accurately maintained by Windows 2000 and should not be used.
BadPasswordCount - This field contains the number of logon or password change attempts with bad passwords, since the last successful attempt.
* UserId - This field contains the relative Id for the client.
PrimaryGroupId - This field contains the relative ID for this clients primary group.
* GroupCount - This field contains the number of groups, within the clients domain, to which the client is a member.
* GroupIds - This field contains an array of the relative Ids and attributes of the groups in the clients
domain of which the client is a member.
* UserFlags - This field contains information about which fields in this structure are valid. The two bits that may be set are indicated below. Having these flags set indicates that the corresponding fields in the KERB_VALIDATION_INFO structure are present and valid.
#define LOGON_EXTRA_SIDS 0x0020
#define LOGON_RESOURCE_GROUPS 0x0200
LogonServer - This field contains the NETBIOS name of the KDC which performed the AS ticket request.
LogonDomainName - This field contains the NETBIOS name of the clients domain.
* LogonDomainId - This field contains the SID of the clients domain. This field is used in conjunction with the UserId, PrimaryGroupId,and GroupIds fields to create the user and group SIDs for the client.
UserAccountControl - This fields contains a bitfield of information about the clients account. Valid values are:
#define USER_ACCOUNT_DISABLED (0x00000001)
#define USER_HOME_DIRECTORY_REQUIRED (0x00000002)
#define USER_PASSWORD_NOT_REQUIRED (0x00000004)
#define USER_TEMP_DUPLICATE_ACCOUNT (0x00000008)
#define USER_NORMAL_ACCOUNT (0x00000010)
#define USER_MNS_LOGON_ACCOUNT (0x00000020)
#define USER_INTERDOMAIN_TRUST_ACCOUNT (0x00000040)
#define USER_WORKSTATION_TRUST_ACCOUNT (0x00000080)
#define USER_SERVER_TRUST_ACCOUNT (0x00000100)
#define USER_DONT_EXPIRE_PASSWORD (0x00000200)
#define USER_ACCOUNT_AUTO_LOCKED (0x00000400)
#define USER_ENCRYPTED_TEXT_PASSWORD_ALLOWED (0x00000800)
#define USER_SMARTCARD_REQUIRED (0x00001000)
#define USER_TRUSTED_FOR_DELEGATION (0x00002000)
#define USER_NOT_DELEGATED (0x00004000)
#define USER_USE_DES_KEY_ONLY (0x00008000)
#define USER_DONT_REQUIRE_PREAUTH (0x00010000)
* SidCount - This field contains the number of SIDs present in the ExtraSids field. This field is only valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ExtraSids - This field contains a list of SIDs for groups to which the user is a member. This field is only valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ResouceGroupCount - This field contains the number of resource groups in the ResourceGroupIds field. This field is only valid if the LOGON RESOURCE_GROUPS flag has been set in the UserFlags field._
* ResourceGroupDomainSid - This field contains the SID of the resource domain. This field is used in conjunction with the ResourceGroupIds field to create the group SIDs for the client.
* ResourceGroupIds - This field contains an array of the relative Ids and attributes of the groups in the resource domain of which the resource is a member.
Fields marked with a '*' are used in the NT token.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The FILETIME type is defined as follows:
typedef unsigned int DWORD;
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;
Times are encoded as the number of 100 nanosecond increments since January 1, 1601, in UTC time.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The UNICODE_STRING structure is defined as:
typedef struct _UNICODE_STRING
USHORT Length;
USHORT MaximumLength;
[size_is(MaximumLength / 2), length_is((Length) / 2) ] USHORT * Buffer;
} UNICODE_STRING;
The Length field contains the number of bytes in the string, not including the null terminator, and the MaximumLength field contains the total number of bytes in the buffer containing the string. The GROUP_MEMBERSHIP structure contains the relative ID of a group and the corresponding attributes for the group.
typedef struct _GROUP_MEMBERSHIP {
ULONG RelativeId;
ULONG Attributes;
} *PGROUP_MEMBERSHIP;
The group attributes must be:
#define SE_GROUP_MANDATORY (0x00000001L)
#define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
#define SE_GROUP_ENABLED (0x00000004L)
The SID structure is defined as follows:
typedef struct _SID_IDENTIFIER_AUTHORITY {
UCHAR Value[6];
} SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
The constant value for the NT Authority is:
#define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
typedef struct _SID {
UCHAR Revision;
UCHAR SubAuthorityCount;
SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
[size_is(SubAuthorityCount)] ULONG SubAuthority[*];
} SID, *PSID;
The SubAuthorityCount field contains the number of elements in the actual SubAuthority conformant array. The maximum number of subauthorities allowed is 15.
The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and their corresponding attributes:
typedef struct _KERB_SID_AND_ATTRIBUTES {
PSID Sid;
ULONG Attributes;
} KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
The attributes are the same as the group attributes defined above.
Client Information
The client information is included in the PAC to allow a server to verify that the PAC in a ticket is applicable to the client of the ticket, which prevents splicing of PACs between tickets. The PAC_CLIENT_INFO structure is included in a PAC_INFO_BUFFER of type PAC_CLIENT_INFO_TYPE.
typedef struct _PAC_CLIENT_INFO {
FILETIME ClientId;
USHORT NameLength;
WCHAR Name[1];
} PAC_CLIENT_INFO, *PPAC_CLIENT_INFO;
The fields are defined as follows:
ClientId - This field contains a conversion of the AuthTime field of the ticket into a FILETIME structure.
NameLength - This field contains the length, in bytes, of the Name field.
Name - This field contains the client name from the ticket, converted to Unicode and encoded using "/" to separate parts of the client principal name with an "@" separating the client principal name from the realm name. The string is not null terminated.
Supplemental Credentials
The KDC may return supplemental credentials in the PAC as well. Supplemental credentials are data associated with a security package that is private to that package. They can be used to return an appropriate user key that is specific to that package for the purposes of authentication. Supplemental creds are only used in conjunction with PKINIT[2]. Supplemental credentials are always encrypted using the client key. The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to encrypt the KDCs reply to the client. The PAC_CREDENTIAL_INFO structure is included in PAC_INFO_BUFFER of type PAC_CREDENTIAL_TYPE. Supplemental credentials for a single package are NDR encoded as follows:
typedef struct _SECPKG_SUPPLEMENTAL_CRED {
UNICODE_STRING PackageName;
ULONG CredentialSize;
[size_is(CredentialSize)]PUCHAR Credentials;
} SECPKG_SUPPLEMENTAL_CRED, *PSECPKG_SUPPLEMENTAL_CRED;
The fields in this structure are defined as follows:
PackageName - This field contains the name of the package for which credentials are presented.
CredentialSize - This field contains the length, in bytes, of the presented credentials.
Credentials - This field contains a pointer to the credential data.
The set of all supplemental credentials is NDR encoded in a PAC_CREDENTIAL_DATA structure:
typedef struct _PAC_CREDENTIAL_DATA {
ULONG CredentialCount;
[size_is(CredentialCount)] SECPKG_SUPPLEMENTAL_CRED Credentials[*];
} PAC_CREDENTIAL_DATA, *PPAC_CREDENTIAL_DATA;
The fields are defined as follows:
CredentialCount - This field contains the number of credential present in the Credentials array.
Credentials - This field contains an array of the presented supplemental credentials. The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to encrypt the KDC reply. The resulting buffer is returned in the following structure:
typedef struct _PAC_CREDENTIAL_INFO {
ULONG Version;
ULONG EncryptionType;
UCHAR Data[1];
} PAC_CREDENTIAL_INFO, *PPAC_CREDENTIAL_INFO;
The fields are defined as follows:
Version - This field contains the version field of the key used to encrypt the data, or zero if the field is not present.
EncryptType - This field contains the encryption type used to encrypt the data. The encryption type uses the same values as the defined encryptions types for Kerberos [1].
Data - This field contains an array of bytes containing the encrypted supplemental credential data.
Signatures
The PAC contains two digital signatures: one using the key of the server, and one using the key of the KDC. The signatures are present for two reasons. First, the signature with the servers key is present to prevent a client from generating their own PAC and sending it to the KDC as encrypted authorization data to be included in tickets. Second, the signature with the KDCs key is present to prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_KDC_CHECKSUM respectively.
The signatures are contained in the following structure:
typedef struct _PAC_SIGNATURE_DATA {
ULONG SignatureType;
UCHAR Signature[1];
} PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
The fields are defined as follows:
SignatureType - This field contains the type of checksum used to create a signature. The checksum must be a keyed checksum.
Signature - This field consists of an array of bytes containing the checksum data. The length of bytes may be determined by the wrapping PAC_INFO_BUFFER structure.
For the servers checksum, the key used to generate the signature should be the same key used to encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the servers TGT should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDCs checksum.
The checksums are computed as follows:
1. The complete PAC is built, including space for both checksums
2. The data portion of both checksums is zeroed.
3. The entire PAC structure is checksummed with the servers key, and the result is stored in the servers checksum structure.
4. The servers checksum is then checksummed with the KDC's key.
5. The checksum with the KDC key is stored in the KDC's checksum structure.
PAC Request Pre-Auth Data
Normally, the PAC is included in every pre-authenticated ticket received from an AS request. However, a client may also explicitly request either to include or to not include the PAC. This is done by sending the PAC-REQUEST preauth data.
KERB-PA-PAC-REQUEST
include-pac[0] BOOLEAN -- if TRUE, and no PAC present,
-- include PAC.
---If FALSE, and PAC
-- present, remove PAC
}
The fields are defined as follows:
include-pac - This field indicates whether a PAC should be included or not. If the value is TRUE, a PAC will be included independent of other preauth data. If the value is FALSE, then no PAC will be included, even if other preauth data is present.
The preauth ID is:
#define KRB5_PADATA_PAC_REQUEST 128
References
1 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-
revisions-05.txt, March 10, 2000
2 Tung, B., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., " Public Key Cryptography for
Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000
HTML and formatting errors are mine (Anonymous Coward's).
The guy writes installer scripts for a living. Every other unix has a Bourne shell implementation except Linux, and Linux's /bin/bash has incompatibilities. Telling the guy to fuck off and use something else has got to be the most ignorant thing I've ever heard. I'm sure he can tell his boss the same thing, right? "Fuck this, I'm gonna use ksh so it works on... AIX only!"
Ask Slashdot becomes less helpful by the nanosecond.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Ever try ash? Here's a size comparison just to intrigue you a bit.
assert(expired(knowledge));
I couldn't say for other distros, but Debian policy says that /bin/sh can be any POSIX-compatible shell, with the one extension that 'echo -n' must not generate a newline. If any script uses /bin/sh assuming bash features, it's considered a serious-level bug.
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
Are you kidding? Bash is light-year ahead of the ms-dos prompt.
For information on Korn shell, see http://www.kornshell.com/
With ksh, you can more easily interoperate with commercial UNIX systems, which now a days all come with ksh.
I've read the list of differences in the FAQ. It's just a big list of extensions to the Bourne shell. It doesn't list any incompatibilities (except for a couple of obscure missing features which you probably shouldn't use anyway). If you write something in standard Bourne syntax, there should be no problems with Bash.
:)
If you, on the other hand, test it with Bash, and then assume it will run under any other Unix... Well, you shouldn't do that with GNU software
commit travesties like "export FOO=bar"
Why is that a travesty? It's clear - clearer than "FOO=bar; export FOO" - and logical.
The fucking bourne shell should be updated to match it... never mind dragging everyone else down to its level of mediocrity.
not to mention the fact that your "suggestion" totally ignore the guys problem: writing a cross-platform install script. zsh is totally non-standard, so that's out. ksh is pretty common, but not totally common, and is installed as different things in different places. there's definatly a place for a standard (you linux guys remember those, don't you?), and, for the time being, bourne shell's it. so either linux gets with the standard program, or it continues to be a pain.
i speak for myself and those who like what i say.
I don't know the exact reason why... I barely know anything about shell scripting... but some shells that say /bin/sh will only work on my system if they use bash. Ash fails due to some difference in how it handles parentheses or file names or something... hopefully someone who knows shell scripting can elaborate ;)
-- Is "Sig" copyrighted by www.sig.com?
"If bash is invoked with sh as its name (argv[0]) then its supposed to act like Bourne - but that just doesnt happen (for example: export FOO=bar is *not* valid Bourne shell syntax, you must say FOO=bar; export FOO)" Not quite right. the syntax export VAR=VALUE is a shorthand method. It is still perfectly alright to VAR=VALUE and then export VAR. I've not run into a comptability problem running scripts under bash, but that does not mean they exist. You can of course recompile bash to function differently ie, for statements can act more like C for statements then their bash versions. Still, tinkering with your shell nulls all warranties, in a sense anyway. Bash has a huge install base and is most likely the shell you will find on most linux systems. If you are really interested in supporting it, you will most likely have to code around its problems. ie, doing a revision check and using X function instead of Y.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Debian kernels are now compiled with initrd support. They use ash for their kernel boot scripts. I'm guessing this is because of it's size.
However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.
You have to use /bin/sh and test on all platforms. There isn't anything else you can rely rely on finding on all distributions. Yes, there are probably slight differences between what purports to be /bin/sh on various platforms, but I can't imagine it will be very hard to write a script that runs fine under all of them---just avoid the dark corners.
Suggestions for other shells (ash or whatever) that might be better are pointless for your purposes because you can't rely on them being there.
I know from experience that (some?) 1.x Bash versions have a bug in the getopt builtin. The bug seems to be fixed in 2.x versions (not sure what version fixed it). There is a workaround for the bug, but it breaks portability of the script. The workaround also causes the script to break for fixed versions of Bash.
That's absurd. You don't have any problem with !#/bin/bash ?
/bin/bash
/bin/sh - we'll leave the where does bash belong debate for another day, but if you wrote an sh script, run it with sh, it's as simple as that.
I do. I don't have
If you don't require any bash extentions, run the script with
It's not my fault Joe Linux Distro doesn't include a regular sh.
From what I can tell from the documentation and man page, ash is just BSD's /bin/sh. Do the BSDs use GNU Bash, assuming the admin wants Bash on the system at all?
No other OS puts bash under /bin.
Except for Solaris 2.7 and 2.8. Ahem.
News for Nerds. Stuff that Matters? Like hell.
...been to thinkgeek lately?
Use the source, Luke!
Use The Source, Luke!
...submit a fucking patch, dickwad.
Sheesh. Some people's kids!
-I like my women like I like my tea: green-
is the last thing linux needs to succeed at the moment.
so why ask for people to write one, if it lacks in totally different places.
a question from me maybe:
is it possible to scale linux down, put (insert the most user-friendly windowmanager here) in it, and keep all those server stuff (appache, bind etc.) out put it on one cd, make an easy installer with good hardware detection, make a framework that 3rd party software vendors can work on without colliding with the GPL's issues, eye candy - multiuser support. and ease the pain of windows users.
ah ya, and dont forget to write a script that makes the delete and backspace buttons work under every terminal-emulator.
except on the *NIX that is growing the fastest, Linux, KDE is still include as default in every major distrobution except for RedHat. It is also default in the second largest *NIX, FreeBSD.
Face it, gnome is dead. all of the gnome developers should switch to KDE or else their work will be at loss.
The things that matter are first, the things sh has that bash does not (from the FAQ):
* uses variable SHACCT to do shell accounting
* includes `stop' builtin (bash can use alias stop='kill -s STOP')
* `newgrp' builtin
* turns on job control if called as `jsh'
* $TIMEOUT (like bash $TMOUT)
* `^' is a synonym for `|' * new SVR4.2 sh builtins: mldmode, priv
* redirection to/from compound commands causes sh to create a subshell
* bash does not allow unbalanced quotes; sh silently inserts them at EOF
* bash does not mess with signal 11
* sh sets (euid, egid) to (uid, gid) if -p not supplied and uid < 100
* bash splits only the results of expansions on IFS, using POSIX.2 field splitting rules; sh splits all words on IFS
* sh does not allow MAILCHECK to be unset (?)
* sh does not allow traps on SIGALRM or SIGCHLD
* bash allows multiple option arguments when invoked (e.g. -x -v); sh allows only a single option argument (`sh -x -v' attempts to open a file named `-v', and, on SunOS 4.1.4, dumps core. On Solaris 2.4 and earlier versions, sh goes into an infinite loop.)
* sh exits a script if any builtin fails; bash exits only if one of the POSIX.2 `special' builtins fails
None of these seem to me to be show-stoppers if you are writing the script from scratch (or even porting a reasonably written one)--I mean really, are you counting on it to dump core if you use multiple option arguments? Is there some reason you can't ballane your quotes? So my question to the_code_poet is, what exactly are you trying to do in sh that won't work in bash?
--MarkusQ
For making a shell that is incompatible with non-free OS?
I even submitted a story about it, but it was rejected:
This sig under construction. Please check back later.
right here, free for everyone to download.
Or actually, this is what _will_ be POSIX next year or so.
"START PROGRAMING PORTABLY!!", to quote that post.
bashing microsoft, I believe.
But bashing bash?
As a current tcsh user under OS X I feel the need to be Bourne again.
i wonder if there is a bashdot.org..I'll go look.
(j/k)
If it is not on fire, it is a software problem.
I apologize if my tone comes off confrontatively :-).
/bin/sh but use bash-specific features, I agree.
I'm reacting negatively to the idiotic suggestion that people need to waste time "writing a real Bourne shell for Linux".
If you don't like bash, there are several other shells which attempt to be POSIX. Some of them are quite strict (ash). Some are optimized for scripting (ksh).
If you want to argue that bash sucks and should be replaced as the default system scripting shell, I totally agree. If you want to say that it sucks when scripts request
But for goodness sake, give some respect to the work that's been done.
...
I did see one good post noting the bash specifics that are missing, as a POSIX shell. They really are quite minor...
that's the dumbest thing i've ever heard... this compare the memory usage of WinXP and bash is rediculous...
Simple bash -- A phrase I'd never expect to hear!
On my system:
131072 sh
688128 bash
Shut up, be happy. The conveniences you demanded are now mandatory. -- Jello Biafra
"would anyone out there be interested in writing a real Bourne Shell for Linux?"
First you will have to tell us what a "real" Bourne shell is. It's not as if there is a standard.
You might or might not like ash. It is much smaller than bash, but on the other hand it tries even harder than bash to be POSIX compliant.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I can understand the reason for this when writing an install script - specifically it is desirable to write to the lowest common denominator and thus make it compatible with everything.
However, I can't think of a single shell which actually implements just POSIX, or Bourne syntax for that matter. There are dozens of shells out there which all will chew on a real POSIX or Bourne script and spit out something which is pretty close to what the script author intended. However it seems that all of the shell authors have done stuff a little differently than each other so if you've only written and tested on one shell, you might have problems running on any one (or all) of the other shell(s).
The best thing to do is to pick something small which is as close to just POSIX implementation as you can get (ash perhaps?) and write/develop in that shell and then thouroughly test it on things like bash, ksh and other POSIX shells.
I always like to through out the fact that most systems now have perl available on them and in some cases it is probably just as appropriate if not more so to script install stuff in perl.
http://hpux.connect.org.uk/hppd/hpux/Shells/bash-2 .05/
i use it everyday at work. i suggest looking around for things you want rather than just asking for them.
solaris sucks - because it doesn't come with bash.
It's ok saying "I want it to be portable, but linux and BSD don't have a proper shell like the archaic solaris and Xenix systems". How about getting sun to install a half-usable shell by default on their systems then? Then you can write "/bin/bash" at the top of your script and know that you're using a defacto standard. Alternately, a bunch of linux coders could waste their time writing an inferior shell.
Time to get your pension, guys.
bash is "more or less the same as the real Bourne shell", will some additions... read the FAQ that was supplied
I have encountered errors with the built-in test with -e tests, eg::
[ -e file.foo ] && something
The problem is really hard to reproduce. It has occurred on both the bash delivered with Solaris 8 and HPUX 11i, but not under Linux. Strange.
Has anyone else seen this?
do my market research (read: job) for me.
I personally don't like bash. For one thing, I don't like its syntax. Well, actually, that's pretty much the only thing. I like csh a lot better because it's easier to configure, easier to use, and has a syntax that I like a lot better. (Hey, I figure UNIX is programmed in C; why shouldn't it be used in C as well (or at least in something C-like).) It's too bad csh wasn't the de-facto standard for UNIX systems, instead of sh. OH WELL.
Bash 1.0 was released Jun, 1989.
Do the math. You are wrong, sir.
MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMM
I've run into this problem in the past as well. My solution was to abandon Bourne shell as a scripting shell and use ksh instead. To be 100% portable, you should use Bourne, but most of your major *NIXes have support for ksh (including linux, Solaris and AIX..not sure about HP-UX) and it has a lot of nice scripting gizmos like associative arrays, printf command, co-processes, pattern matching, etc. Of course, maybe you don't need all of that stuff.
As an aside, there has been a lot of extensive research on making portable shell scripts. Bruce Blinn's book Portable Shell Programming: An Extensive Collection of Bourne Shell Examples is a good resource that might help as well as GNU Autotools documentation, which is the definitive guide on this sort of thing. Another useful jumping off point that has some good materials and a lot of useful links is Shell Script Porting Guidelines
"it is annoying that you can't solve the efficiency problem by relinking /bin/sh to ksh or ash, since all the system scripts will do slightly-non-POSIX things and therefore should be specifying /bin/bash"
/bin/sh and not have anything break. For my own scripts (some of which have run to 1000 lines) I confine myself to sh features documented in my old copy of Kochan and Wood.
Debian policy requires that scripts that use bashisms (that is, non-POSIX features) use #!/bin/bash and not #!/bin/sh. The goal is to be able to link any POSIX shell to
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Bourne a shell, always a shell...
Ceci n'est pas une sig
and you're using the same rediculous exaggerating that makes your (stupidly obvious) comments overlooked... just 'cause bash takes (way) more memory than sh, does not mean you'll need to go out and get another DIMM (even as cheap as they are)... and if bash pushes you over the edge into needing more memory, then you were already over the edge as far as i'm concerned, cock-gobbler
How about a nice warm glass of SHUT THE HELL UP.
Do any of your target platforms not have ksh88? PDKSH is rock solid, and the few incompatibilities are insignificant and documented. I believe OpenBSD uses it as /bin/sh. I've been using it for years and highly recommend it.
/bin/sh could probably be ported to linux pretty easily. I believe it's derived from ash. I don't think it's perfectly compatible with Bourne's original, though.
Alternatively, the FreeBSD
A bash link would be just as apropòs.
Check out this Bash website for more information on how to make Bash more sh-compatible.
for an installer, I'd say it wasn't crazy idea; and for a user's shell, of course it's nuts, but we're talking about an install script.
you can _always_ count on perl being there (right?). any unix not having at least perl5 is not a unix system, in modern terms.
personally, I prefer tcsh as my _user_ shell. and its a pretty complete version of the c-shell, but made more livable.
--
"It is now safe to switch off your computer."
Hello, what planet are you on? The csh looks nothing like C. The syntax is clumsy and inflexible. See Csh Programming Considered Harmful.
Not only that, but csh is actually older than the bourne shell!!! It was derived from 6th Edition Unix, the bourne shell was new in 7th Edition. Talk about being slow to catch up...
Seriously, there is very little (most would say none) incentive to use csh anymore. Even in its tcsh incarnation, it's almost completely been superceded by zsh. You should check it out for your own sanity.
Should you desire, you can even turn on the god-awful insane history mechanism that all those weird-ass csh users seem to have gotten ingrained with...
The Linux packaging system for each of the distribution(s) you are targetting. That means packaging each for Debian, RedHat, and possibly others.
Here's one: Richard Grey feat Tiza B. - You Can Run
I don't know. There's a shitload. Go look around.
The POSIX shell standard is much closer to ksh than to Bourne shell. If that's what you want, ash is pretty much what you described.
Problem is, ksh / POSIX sh is not the lowest common denominator - there are old systems out there that still only have Bourne. (Contemplate for a moment, if you will, the design decision of the autoconf author not to rely on the existence of shell functions! Even Bourne shell has had those since the mid-80s or so.) Most vendors don't seem to care about pre-POSIX shells any more, though.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Wow, do you mean with ash I could use a Pentium III 780 instead of 866? Let's face it, given Moore's law, any speed improvement less than n vs. n^2 is more or less irrelevant.
As for memory usage, bash is about 0.5 megabytes, any memory chip that small is obsolete, and very expensive. Better get 64 megs or more, compared to which both sh and bash are about zero size.
In the dependencies issue, I admit you are right. But so many other packages need those same libraries that it's very likely you'll need them anyhow.
All in all, I think this "sh or bash" thing will be an issue only in a very few restricted cases, mostly embedded systems.
/.
I always install bash on the other unixes I run; and in our shop there is a movement afoot among the app coders to make #!/bin/bash a *requirement* for shell scripts.
One reason. Portability! You see, the so-called Bourne shells on the various proprietary unices are NOT ACTUALLY COMPATIBLE. That's right, there have been code forks in proprietary unix!!! News at 11!!
DEC's sh is not source-identical with Sun's, and of course HP-UX (a hideous train-wreck of a unix) comes with two subtly different sh implementations - the "posix" sh (which is almost posixly correct, except for the bugs) and the "bourne" sh (which has differing bugs).
Bash, on the other hand, is free and open source, and thus can be compiled on anything that can run gcc and it will act substantially the same (of course on HP-UX underlying OS bugs occasionally bleed through, but that's not really avoidable).
So the best solution would probably be to make bash faster smaller better (with free checking and 40% more trunk room when you order the Ginsu wind chimes) instead of making yet another Bourne code fork.
--Charlie
Posting anonymously because I'm too lazy to look up my password....
We've been using ksh/pdksh very successfully in our projects. As of now, we've got about 200+ ksh scripts and they run perfectly in Linux (Intel and AXP), DG/UX, Solaris, HP/UX and AIX. And no, we haven't hit a single pdksh incompatibility yet.
HPUX has a pre 1988 version of ksh. The CDE distro has ksh93. These are the standared shells for HPUX.
Comment removed based on user account deletion
The funny thing is that, even though this is a troll, the replies that have come with this troll are funnier. Consider:
"Choice in GUI is good! You're locked into one consistent interface in Windows!"
"Dump open-source, and you dump freedom!"
"OpenOffice/KOffice is getting there! I would recommend it to my grandmother _and_ my nephew!"
"rpm -Uvh kernel*.rpm"
( yeah, and get this error message:
error: ALL THE PROGRAMS ON THE SYSTEM DEPEND ON OLDKERNEL, YOU HAVE NO CHANCE TO SURVIVE MAKE YOUR TIME )
a light-year is a unit of distance, not time.
why are you comparing dates of release?
(by the way, I'm pretty sure unix had an interactive shell before MSDOS 1.0)
... but it's always on core ...
"Video bona proboque; deteriora sequor." -- Ovid
Are you all fools? Can you not read English?
He's not saying Bash is bad.
He's saying Bash is NOT compatible with other Unixes.
He wants to develop on Linux and have it work on other Unixes also.
Fools!!
Others have addressed the various issues about what is a "real" Bourne shell and bash extensions and all that. Anyway, the Linux Standard Base has a section on shells. In a nutshell, bash 2.x was the most POSIX-compliant of the shells that the LSB tested (and no, I don't know exactly what versions or which shells or the like), with pdksh getting an honorable mention. And there were two ways in which bash was not POSIX-compliant and concerning which the LSB therefore diverges from POSIX (whether $0 is the full pathname or just the basename, and what happens if you try to use "." to run a script without the read bit set). I don't know whether a future version of POSIX is planning to change the specification, or whether this is likely to remain a divergence for the foreseeable future or what. In any event, these two issues shouldn't be hard to deal with in writing scripts.
The following works in UNIX sh, but not in bash:
echo $user $group
done
To work around the bug you can either put the output of ls into a file and redirect input to read from the file, or you can use an immediate mode file (EOF) in the script, but pipes are broken with respect to read.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
The example you mention, export FOO=bar is a valid POSIX syntax. /bin/sh implementation. True, it does
/bin/sh. Debian tries to be
POSIX as well as the standard Unix specification mandates that this
should work on any conformant
not work in the original Bourne Shell, and there are old systems where
this may not work. The other commonly used non-Bourne compatible
feature are the ${...%...} and ${...#...} substitutions, but that is
also POSIX compliant. The original Bourne shell had many problems
that made it difficult to use for scripting, and I think it is a good
thing that POSIX clarified many aspects of the shell behavior, and it
also added some new feature mostly taken from the Korn Shell. Today
any system that claims to be Unix must support these features.
You also mentioned scripts that work in the original Bourne shell but
break with bash. If it is a bug in bash, write a bugreport, and try
to find a workaround. There are bugs in commercial shells as well,
and if you want a portable application, you must work around them.
There is no easy route to portability, some systems, especially old
ones are broken beyond belief, and the only way to find such problems
is to release your program and let the users report the bugs. And if
you want a fast scripting language, you can also use ksh, I believe it
is standard on most commercial Unixes. On Linux pdksh is available as
well as AT&T ksh93. pdksh is smaller and much faster than bash. You
can also use ash, I think it is the BSD
ash compatible, if something in Debian does not work with sh linked to
ash, file a bugreport.
A good way to learn some portable shell programming is to look at GNU
configure scripts generated by autoconf. It can be tiresome to write
shell programs with bug-compatibility in mind, but you can get used to
it.
The korn shell is supposed to be 'the' POSIX compliant shell and ships with all commercial unix systems. So if cross platform compatability is required, korn is the logical choice.
Why would anyone choose to write scripts in sh anyway, it's like writing using a chisel a stone. Ksh at least has 2D arrays, and some pretty decent builting functions for pattern matching.
# .bashrc
/etc/bashrc ]; then
/etc/bashrc
] \h $COLOR3\[\262\261\260\]Ä($COLOR1\$(date +%H:%M:%S)$COLOR3)Ä($COLOR1\w$COLOR3)Ä$COLOR4\n$CO LOR3ÀÄ($COLOR1\u$COLOR3)$COLOR3 $COLOR2\$$COLOR4 "
:\[\033[0m\] "
R 4$ GRAD1$COLOR6'\t '$NONE'\n'$COLOR5'\u'$COLOR8':'$COLOR7'\w'$COLOR8' \$'$GRAD0''
L OR 5'>'$GRAD0'
if [ -f
.
fi
COLOR1="\[\033[1;33m\]"
COLOR2="\[\033[0;32m\]"
COLOR3="\[\033[0;31m\]"
COLOR4="\[\033[0m\]"
PS1="$COLOR3ÚÄ\[\260\261\262\]\[\033[00;30;41m\
PS2="$COLOR2>$COLOR1Ä$COLOR3Ä$COLOR4 "
#PS1="\[\033[1;32m\]\w\[\033[1;31m\]
# title on Xterms etc.
if [ "$DISPLAY" != "" ] ; then
export PROMPT_COMMAND="echo -en '\033]0;'\`hostname | cut -f1 -d.\`-\`tty| cut -f3 -d\/\`'\007'"
fi
cd
#GRAD0='\[\033[00m\]'
#GRAD1='\[\333\262\261\260\]'
#GRAD2='\[\260\261\262\333\]'
#COLOR1='\[\033[01;32;46m\]'
#COLOR2='\[\033[00;30;46m\]'
#COLOR3='\[\033[00;34;46m\]'
#COLOR4='\[\033[00;34m\]'
#COLOR5='\[\033[00;32m\]'
#COLOR6='\[\033[01;37m\]'
#COLOR7='\[\033[01;32m\]'
#COLOR8='\[\033[00;37m\]'
#PS1=$COLOR1$GRAD1$COLOR2'\h'$COLOR3$GRAD2$COLO
#PS2=$COLOR1$GRAD1$COLOR3$GRAD2$COLOR4$GRAD1$CO
a lot of slashdotters have pointed out this is a non-issue; as far as writing scripts goes, so long as you are "careful" you won't run into any problems.
right? i mean exactly how hard is it, knowing, loving, and using bash to click-off the parts of your programmer mind that deal with the bashism shortcuts you take for granted?
as a programmer, i frequently need a few steps to shift gears. i'll be working for four or five hours on some C, flip into a perl program and find myself (quite unconsciously) dropping some $char@act%ers*. they're deceptively similar languages in construct, and i must say "okay, now i'm writing perl" or java or bash or forth or whatever.
this is not to suggest that our friend in need is without hope; that even if he had a real bourne shell he would still make mistakes. this simply illustrates that it's more difficult to avoid those mistakes EVEN WITH the knowledge.
if you're a non-programmer, don't bother responding to me, because it's hopeless to think you'll understand... just because you can quote the linked faq doesn't mean you actually understand it.
the case of typing export out is such a silly one that I often make the same error: i have a rather large administration tool that runs on NT, 2000, Solaris, Linux, and OpenBSD. It's goal is to unify their various differences so that administration can remain (roughly) the same.
as such, it's a myriad of shell scripts, 300-400 line C programs, perl programs, wrappers, and whatnot. the MOST COMMON PROBLEM that I deal with is because I develop initially on a Linux system. Linux is extremely developer friendly (perhaps because it was developed for developers, but that's a hiyku waiting about that i'm not going to release today) - and solaris, NT, and 2000 are not (again, YOU can disagree; I know many hailstorm developers that love the new windows platform. you're still wrong.)
however. i did mention that there was hope, and to that i will now digress: your application (whatever it is) must SOMEHOW share some commonalities with the platforms in which you wish it to run.
if your application is a C program: write your installer in C. or better still? write makefiles. perl program? even easier: you have a shell (perl, well, sort of). if your program is a bash script (and i'll pity you if it is) you simply require the use of bash.
i make my administration tool work on many platforms by making those platforms more similar- that way the jump is shorter.
i also have the added benefit of being able to test my changes. they go from my development machine to a staging system (one of each flavor) and from there onto the production webs.
i can't very well suggest that you "avoid making mistakes", and if I suggest "ash" or "zsh" or "csh" i'm simply suggesting that you require something else. i'm not going to have any allusions about it, however: if it doesn't work, use something else ANYTHING else. even if that means you need to slap solaris on a machine (for bourne), or perhaps stealing the *bsd's shell.
you have more than your two (obvious) options- in extremeties and in directions. remember your goal first, and then find out what problems exist.
best of luck
Must be an Albany graduate. For some reason (at least when I was there), csh was your default shell. If you were lucky you got it changed to tcsh before they disabled ypchsh for "security reasons". Bash? Nobody used it. I remember setting up Linux for the first time back then, trying to figure out how the heck environment variables worked in Bash. I knew this was a goddam simple question, but nobody at school knew because everyone there had only seen C Shells. I also knew that asking a question like "How do I set environment variables in Bash" on the net would not get me the answer. But at the time, a file that said "FOO=bar ; export FOO" or "export FOO=bar" was not that easy to find. I don't know why they continued to use CSH scripts for everything even when it appears everyone else in the world uses bash.
just use csh!
Ugh. The guy is writing an installer for software which runs on different platforms, of which linux is only one of them.
Software installers have to be tested on each platform, not so much because of the install shell script, but because the platforms will vary so widely.
The bourne vs bash problems are the least of his worries - finding out what Redhat broke and/or moved in their latest release is more like it - or (one of my favorites) that Solaris 8 had a bug that caused a 2 GIG malloc() when the tail command was called...
Since HP-UX 11 came out I believe /bin/sh is the POSIX shell. Not really Bourne exactly.
And I think most of us are bright enough to test our code a bit on those platforms for which we are responsible. Whining about shell discrepancies is a bit lame. What happened to the news?
- Sig this!
Sun uses the older ksh for some odd reason.
It's neither sh nor the latest ksh.
Who uses Algol today? We now have much more elegant shells like "rc", either the "rc" clone that is shipped with most Linux systems, or maybe even the original Plan 9 "rc" designed and written by Tom Duff.
There is some room for improvement in the art here. It bothers me that the first goal is to be compatible with something that ran in 1971.
Thanks
Bruce
Bruce Perens.
If we did that, We'd be MS.
No thanks.
Real Bourne Shell will be released as source code sooner or later by Caldera. Here is the press release:
http://news.linuxprogramming.com/news_story.php3?l tsn=2001-08-20-003-06-CD
http://ir.caldera.com/ReleaseDetail.cfm?ReleaseID= 57417
And here are some quotes:
So, you must keep you eyes on this:
http://unixtools.sourceforge.net/
Meanwhile you can do portable shell-scripting with help from these WWW-pages:
http://www.raycosoft.com/rayco/support/porting.htm l
http://www.raycosoft.com/rayco/support/SANS_2001_f iles/v3_document.htm
http://sources.redhat.com/autobook/
http://sources.redhat.com/autobook/autobook/autobo ok_208.html
Ash is really good Bourne Shell clone and POSIX-shell implementation. I really like to use it for my shell-scripting, because it prevents me from using bashisms. In my Debian GNU/Linux 2.2 Potato /bin/sh is actually a symlink to
ash that I compiled from sources I took from unstable Debian and it works.
But if /bin/sh is symlink to bash and you have some bashisms in you script that
starts "#!/bin/sh", it seems, that even in that case bash won't complain
about those bashisms.
But you must check out, which version of ash you are running. Debian has always used the latest version of ash. I think it is downloaded from this place:
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src /bin/sh/
Red Hat Linux had ash version 0.2 and it really sucks. Then I made bugreports and latest versions of Red Hat have fresher version of ash.
But it seems, that Slackware still has that ash version 0.2:
ncftp ...ware-8.0/source/ap/ash > pwdc kware-8.0/source/ap/ash/ ...ware-8.0/source/ap/ash > ls ...ware-8.0/source/ap/ash >
ftp://ftp.slackware.com/pub/mirrors/slackware/sla
ncftp
ash-linux-0.2.diff.gz _ash.tar.gz
ash-linux-0.2.tar.gz SlackBuild
ncftp
BTW I really don't understand, why somebody would want to create installer scripts, when this kind of tool exists: http://www.easysw.com/epm/
Juhapekka "naula" Tolvanen - http://iki.fi/juhtolv
It's nice, fast, consistant, it's available for all UNIX platforms (as far as I know), and it's less of a pain in the ass than writing a shell script.
Perl works really really well for these kinds of things, I'm suprise most people don't use it.
csh is fine for interactive use even Tom "csh Considered Harmful" Christiansen uses tcsh interactivly. Just don't use it for scripting.
If you don't like the FreeBSD answer:
Go to SCO and buy the unix legacy licence, and port the REAL sh.
Linux is a KERNEL. You are complaining about a distro, any one of the 190+ versions. Try different versions till you find the one that works as you want.
The IEEE Standard 1003©2 ¥``POSIX©2'' specification for the shell©
Best Slashdot comment ever
Goddamn queers. Learn some shit about linux before you post like an idiot.
RPM is the only packaging system that matters.
It soon will be the Linux Standards Base (LSB) package manager.
This is somewhat OT but I think it is a valid point. How bout...a better shell to replace sh on those "enterprise" *nixen. I have not quite figured out why the "big guys" have not grown up a bit and started using more robust shells like bash and/or ksh. Frankly, I'm a korn shell guy when it comes to scripting jobs which is what I do for a living (ksh and Perl). Solaris ships with ksh88 out of the box. Solaris 8 might actually come with ksh93 now (NOT including dtksh which is a superset of ksh93 with dt code built-in) but I could be mistaken about that. However, Solaris still bumps into borne if one needs to go into maintenance mode. Now, I am not a hard-core Unix code hacker and I don't proclaim to know everything about Unix, but I have my fair amount of knowledge. No doubt, the first reply to this will be: It can't be done because of compatibility issues. BAH! I really do not think it would be that difficult to build and use the more up-to-date shells into the vanilla installs for those enterprise type *nixen. Why would you change? I know bash finally added support for arrays not too long ago (a couple years now?). Korn does arrays, but borne, does not. Can borne do tertiary conditions? I don't know, never tried but I doubt it. Does borne allow all of the test switches that bash and korn can do? The ever-loved command-line recall is a good 'nuff reason to do away with borne. Borne is old and it's deprecated. Everything has to evolve sometime. I'm not leaving out csh and tcsh on accident. I just am not a cshell kind of guy but I know it is very powerful. FreeBSD uses it as the default root shell in a vanilla installation. I believe even FreeBSD falls back to borne in maintenance mode. I think, in the end, the biggest reason why those Unix companies don't "upgrade" to the more robust shells is compatibility. Perhaps the second biggest reason is, "why? It works!". I agree, it works and if that were the only reason, I admit, that is a worthy reason. However, I feel its time to move on!! Things don't get better if they remain in the old ages.
- J
Ah! Just what we need, another *nix versus Linux argument over some relatively small shell issues.
.NET initiative. The *nix people are too busy getting all pissy about Bourne not being on Linux.
.profile but it's still an sh kludge.
This explains why M$ gets all the press with their
I push bash on a Solaris 2.6 system because I got tired of the lack of command recall (up/down) arrow function in sh. Yes, you can kludge your away around that by playing around with
The *nix people need to grow up and realize the year ain't 1979.
The people who complain that complain about Linux not having a "real" Bourne shell are probably the same group of people who use vi to do all their word processing, *AND* think that vi is the greatest text editor ever written *AND* can't understand why all the clerical/sales/support/executive/management people use M$ Word to write letters.
P.S. I hate vi. I normally used jed, although I frequently wind up using vi because I don't run the gui on my Linux boxes (they are servers, afterall) and jed does not always do what I need it to.
Well, at least he did, back in the day when bash had not really matured and gained market share and no other shell had the useability features tcsh had (tab completion, up/down arrow editing, etc). I wouldn't bet any money that he still does (although I wouldn't bet against it either - who knows, he might).
But bash now has almost all the features people (including me!) liked so much about tcsh, and zsh of course has all those and much much more. So there's no good reason anymore not to switch - well, there are reasons (availability on all machines that you use, availability of people to help you who are knowledgeable in bash/zsh, difficulty of the transition, etc) but the days of tcsh being "easiest to use" are long gone.
Besides, we can't all be the great tchrist - I imagine he has no trouble keeping syntaxes of esoteric features of different shells in his head and not confusing them, but I find it much easier to use the same shell syntax interactively as I use for scripting. That's the biggest reason I switched to bash, lo these many years ago. (Since then I've found many other reasons not to regret the migration.)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
I used to work for a large company that supported nearly all UNIX variants, Linux was an experimental port. The system relied on many Bourne Shell scripts to install and configure on Unix platforms. I was involved (on free time) in doing the Linux ports and getting those installations scripts to run on BASH was a real nightmare. The "little" inconsistencies really made my life difficult.
But don't take me wrong I personally thing BASH is a more than fine shell, I love it. But when it comes to compatibility with SH for commercial software (the one that works on many unixes) then you are in for trouble.
Last I checked, OpenBSD was using pdksh. What's really interesting, the binary was smaller than ash, in spite of having a richer ksh-type syntax and decent command-line editing (both were statically compiled; apples to apples). So pdksh looks like a good choice as a default shell for a system (though not necessarily a good reference Bourne-shell).
well, the original unix had a shell, do the math :)
use Perl;
Actually, is writing korn or bourne shells the way to go?
We're year 2001. ZSH, Bash and Tcsh are there for years, and they work on all platforms out there, including Windows. They provide a lot of enhancements over Ksh and sh (kick-ass completion, readline, floating point arithmetic, a lot of handy shortcuts and builtins, etc) .
So, the way to go is probably to use nowaday's tools, not 20-years old ones.
{{.sig}}
Nowadays, if you install the ash Debian package, it asks you if you want to use it for /bin/sh.
Just remember that when bash is invoked as sh /bin/sh
/bin/bash) bash runs in a bourne shell
/bin/sh is not bash, even
/bin/bash ;)
(that is the link you mostly see from
to
emulation mode, to mimic the behavior of
original bourne shell to the best of its
knowledge. ihmo,
if its a symlink to
What exactly were the "inconsistencies"? How many were there? What features did they involve? I've been in the business long enough to recognize situations where my own unfamiliarity with a particular technology spanks me hard. Perhaps the original poster is finding him/herself in a similarly humbling situation?
The only way to test if your scripts will work on different Unices is: Test them on different Unices. You have only Linux? Too bad, if you really earn your money with that work, buy some other machines. That's professional life, deal with it.
The situation has been spelled out best by Larry Wall in an old Usenet posting:
Since, your problem is: There ain't no such thing as a standard Bourne shell. The real original Bourne shell was a beast - believe me, I've had access to the source. The C code was turned to some pseudo-Algol by way of macros (e.g., #define THEN ) { etc.) Most Unix vendors replaced it by an own implementation sooner or later.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
Haven't you heard the news? There is no NetBSD anymore, you can go home now and play with your new WindowsXP system.
The problem is that Linux programmers don't stop to think about whether the shell they use e.g. during installation or with wrappers, is actually present on the system.
Being a solaris admin I regularly have to edit shell scripts to put the right path for bash in (/opt/local/bin/bash).
Software programmers should make their code more portable. In other words, fix configure to look for bash in the path and use that at the top of installation/wrapper scripts. In normal circumstances making the fixes isn't that much work, but you can see that it becomes much more of a problem when compiling something as humungous as Gnome because you can't automate the compiles/installs.
Cylix, you misunderstood Cliff slightly. He wasn't commenting on valid bash syntax, he was commenting on invalid Bourne shell syntax.
What he said is quite right. He didn't say "FOO=bar; export FOO" was not allowed in bash. Where'd you pick that up from?
Does this sound familar:
/bin/sh gets a defect call from me. There is no reason on earth not to ship and use more robust tools if your install truely is that complicated.
"Why isn't $NEW_SW available?"
"Because the install script crapped all over itself, and I'm trying to figure out what it's doing."
"Didn't you call support?"
"Yeah, but apparently our latest set of OS patches is not something they tested with."
"Did you get an ETA on the fix?"
"A couple of weeks, maybe more."
"But we need it now!"
"I know. That's why I've been here the last two days going over 120k of poorly written, documented and tested install script!"
Any vendor shipping an install that requires more than a few lines of
While I was in college, I would do my work via telnet on Solaris. I discovered after several frustrating minutes that bash was found in /usr/bin instead of /bin. I then saw the regular shell was in /bin so I just used #!/bin/sh for portability.
The Slackware Kornshell is KSH 93 compatible and works fine with other distro's, such as Red Hat.
/, and run the install script from there.
Download it into
FreeBSD uses CSH as the standard shell for single mode, root and users. It has others available, including BASH and KSH, but these must be installed.
Ugh. I do NOT want to target a package to some linux distribution. I want to target a package to linux in general. I don't want to care about all those distribution. My package will most likely work on all of them (hopefully).
So this means that I cannot simply do what you want and take the 'linux packaging solution' because linux does not have a standard packaging solution. All distributions have some but not linux itself. But the packaging systems from the distributions are useless as I don't want to target a distribution.
Greetings,
Project Manager of Crystal Space (http://www.crystalspace3d.org). Support CS at http://tinyurl.com/cb3x4
Yeah, use whatever shell you want interactivly... I personally don't like the way bash does some things (vs tcsh) but I do like zsh. I'm not saying we should all do what tchrist does (though from the comments he's made on it I have the feeling he's not a bash user). I just find that a lot of people seem to misunderstand Tom's paper.
For the record I use csh because because I'm a sysadmin and a real csh is still a lot better to use interactivly than the POSIX shell (not bash).
Sorry you got modded down for being right. If I had real points I give you one, but at present the only mod points I have are the these fake ones I mint for my own private mod system.
-- MarkusQ
Because I keep hearing *BSD is dying.
Why should people have to install or port sh just to run your software? Just make a bash compatible version. That would surely be easier for than a port. i doubt there subtlties about sh that would enhance your installer.
Have you ever heard of shared-copy-on-write executables?
Have you ever heard of shared-copy-on-write executables?
Have you heard of U.S. Patent 4,742,450 on the shared-copy-on-write memory segments that loading such executables requires?
Will I retire or break 10K?
All in all, I think this "sh or bash" thing will be an issue only in a very few restricted cases, mostly embedded systems.
By dismissing embedded systems as a "few restricted cases," you misunderestimate their ubiquity and importance. Go to Worst Buy or Shircuit Shitty and look at the PC section vs. the sections that have TiVo, WebTV, GameCube, etc. Do you see more PCs on the shelf, or more embedded devices on the shelf? For instance, TiVo runs a Linux kernel, and Dreamcast and PS2 also have Linux available. (Sony will soon bring PS2 Linux Kit to the U.S.) Now would you rather run bash (Bloated A$$ SHell), or would you rather run something smaller and be able to add more features on a given set of fixed hardware such as a game console or a poor student's PC?
Will I retire or break 10K?
This actually works pretty well, and it's great for finding broken sh scripts.
From the zsh manual:
"Zsh tries to emulate `sh' or `ksh' when it is invoked as `sh' or `ksh' respectively."
I don't know how strict the sh emulation mode is.
Solaris is the Operating Environment.
It's internal number is 2.8
It's marketed number is 8
SunOS is the unix that operates the system.
It's internal number is 5.8
It's not marketed.
In laymans terms, solaris is like windows 95 or redhat.
SunOS is like linux, or DOS 7.
And just to throw a little more confusion into the works:
Solaris' GUI was OpenWindows,
It is currently CDE (Common Desktop Environment),
It will be GNOME (on top of swordfish?).
I use ash, because it is /bin/sh on FreeBSD which is what I use mostly. I believe it is fairly conservative (that is, doesn't implement much more than a minimal bourne shell). I know the POSIX spec' fairly well. I never have any problems writing incompatible scripts (by, for example, accidentally using features that some other shell doesn't implement). I very occasionally find myself thinking that the bash/POSIX ksh syntax for arithmetic expressions would be nice (usually around the same time that I think I ought to rewrite the script in awk/python/c).
Of course, because I mostly only use FreeBSD I don't get to test my scripts on other shells very often... (HP-UX, OSF, and Ultrix used to be good platforms for finding quirky shells).
The shell I use most often is rc (from plan 9), but I don't do "real" programming in that because no other system has it installed (certainly not by default). Having a fairly even mixture of programming sh and programming rc is a good way to mess up your mind.
This comment has been scanned for viruses.
The only problem I ever ran into was that a lot of people seem to shebang #!/bin/sh on Linux systems, when in fact they're using Bash symantics. This confuses scripts trying to run on systems with a real bourne shell (e.g. Solaris). I don't mind that Linux doesn't have a proper Bourne shell, I just wish coders would properly acknowledge #!/bin/bash.
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
I've written quite a bit of
You either misunderstand or misremembered the explanation. No scripts break when root's shell is changed.
You shouldn't change root's shell because you shouldn't be using the root acount often enough for it to matter. If you use su to become root, use the -m flag so it keeps your existing shell and environment. That's what it's there for. Or, install sudo and use 'sudo bash' to become root. On all my servers I haven't 'logged in' as root in at least 6 months. Linux users use the root account far too often and then carry their bad habit to other OSes when they switch.
The other danger is not being able to use dynamically compiled shells in single user mode. You mentioned this.
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
The modern thing is simply the POSIX shell command language; If you write in the POSIX language, avoiding the quirks and extensions in the proprietary implementation you are using, your script should be highly portable to GNU bash and vice versa.
Similarly, if you want to write a new shell, your best bet is to use the standard as the guide rather than to clone the behavior of the legacy Bourne shell.
If you don't know what is standard and what is not, try the draft Single Unix Specification online.
Search for ``shell command language''.
A linux packaging system, eh? This is make, make install? Or do you mean something like rpm? Or deb?
Look ma, I'm a
Hi:
I do exactly the same thing - one shell script has to install my company's product on Linux, Solaris, AIX, and HP-UX. I develop the scripts on Linux, and I've been bitten in the ass by accidentally using a Bash-only extension. I have found this book to be very helpful:
Blinn, Bruce, _Portable Shell Programming_
ISBN 0-13-451494-7
-Ghengis