Tag Info

Hot answers tagged

36

POSIX first was a standard in 1988 long before the Single UNIX Specification. It was one of the attempts at unifying all the various UNIX forks and UNIX-like systems. POSIX is an IEEE Standard, but as the IEEE does not own the UNIX® trademark, the standard is not UNIX® though it is based on the existing UNIX API at that time. The first standard POSIX.1 is ...


29

Console programs typically use curses or one of its successors to build the sorts of text user interfaces you're talking about. (There are other libraries of this sort, but it's not important to list them all here.) These libraries use one of two databases, called termcap and terminfo. (This is one of the many BSD vs. AT&T differences you still find in ...


23

There is no standard indentation in shell scripts that matters. Slightly less flippant answer: Pick a standard in your team that you can all work to, to simplify things. Use something your editor makes easy so you don't have to fight to stick to the standard.


22

The autoconf manual has a section on portable shell programming. Although that's not specifically targeting POSIX, it's probably the most complete collection of what to do and not to do when attempting to write portable shell code.


22

No, that would be a bad idea. cat hugeregularfile.txt > /dev/null and touch -a hugeregularfile.txt are not the same. cat will read the whole file, even if you redirect the output to /dev/null. And reading the whole file might be exactly what you want. For example in order to cache it so that later reads will be significantly faster. The shell can't know ...


21

Unfortunately there is no guarantee of anything being available. However, most systems will have GNU coreutils. That alone provides about 105 commands. You can probably rely on those unless it's an embedded system, which might use BusyBox instead. You can probably also rely on bash, cron, GNU findutils, GNU grep, gzip, iputils, man-db, module-init-tools, ...


18

No, since /dev/null is just a name, which could be used for any other device or for a file other than what "normally" is a data sink. So a shell (or any other program) has no idea, based on the name, whether the file it is writing to is doing something "for real" with the data. There are AFAIK also no system calls the shell program can make, to determine ...


16

The POSIX 2008 standard has a section describing "Shell and Utilities". Generally, if you stick to that your scripts should be fairly future-proof, except possibly for deprecations, but those hardly happen overnight so you should have plenty of time to update your scripts. In some cases where output format for a single utility varies widely across ...


14

I've never encountered shell specified style guide but for bash programming this is the most popular one: http://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf The indentation of program constructions has to agree with the logic nesting depth. The indentation of one step usually is in line with the tabulator steps of the editor selected. In most ...


13

The behavior of shell utilities does differ in minor ways between unix variants. There are many unix variants, with a complex history. There are standardisation efforts such as the POSIX standard and its superset the Single UNIX specification. Most systems nowadays implement POSIX:2001, also known as the Single UNIX Specification version 3, with minor ...


12

To get a certification you need to pay, and it's actually really expensive, this is what BSD like and GNU/Linux operating system vendors like don't apply to it. So there is even not a reason to check whatever or not GNU/Linux is compliant. http://en.wikipedia.org/wiki/Single_UNIX_Specification#Non-registered_Unix-like_systems Most of all the GNU/LInux ...


12

Greg's Wiki has a post on adapting bash scripts for Dash that points out a lot of 'bashisms' - extra features that are non-standard but are a part of bash. Avoiding those bashisms can help to make your script friendlier to different environments. This particularly answers some of your questions. For instance, yes, there are operators that differ (like ==), ...


12

I'll try to answer from my experience. Commands don't really adhere to a formal specification, but they do adhere to a requirement to consume and generate line-oriented text. Yes, of course. Before the GNU utilities became a de facto standard, a lot of vendors would have quirky output, especially with respect to ps and ls. This caused a lot of pain. ...


12

It will not optimise out running commands (and you've already received a number of fine answers telling you why it should not), but it may optimise out forks, pipe/socketpairs, reads in some cases. The kind of optimisations it may do: With most modern shells, the last command in a script will generally be executed in the process of the shell unless some ...


11


10

In the 21st century, especially if you're targeting machines that are likely to have bash or zsh, you can count on type being available. (It didn't exist in extremely old unices, as in, from the 1970s or early 1980s.) You can't count on its output meaning anything, but you can count on its returning 0 if there is a command by that name and nonzero otherwise. ...


9

Quoting from the Single Unix specification version 2, volume ”Commands & Utilities", §2.13.3: If a filename begins with a period (.) the period must be explicitly matched by using a period as the first character of the pattern or immediately following a slash character. (…) It is unspecified whether an explicit period in a bracket expression matching ...


9

POSIX is a subset of UNIX which is intended to cover various Unix-like environments for other operating systems; this originally included environments such as Eunice for VMS, Windows NT's POSIX personality, and Apollo Domain/OS. You can think of it as a standard portability API for the subset of operating system services whose behavior is in common between ...


9

Yes and no. In a POSIX environment, the utilities must behave as described by the specification. In practice, this means that conforming versions of the utilities must be present in $PATH. However, when running your program on a POSIX-compliant system, you may be running it in a non-conforming environment. In practice, what often happens is that the OS has a ...


9

First, very brief answers to your questions: Formal standardization of input/output conventions: no Breakage in the past due to changing output: yes Absolutely impossible to break future filters: no How can I protect myself against changes: be conservative When you say "API", you're using a term that (for good or ill) implies too much formality around ...


7

This is not distro specific so much as Desktop Environment or Window Manager specific. First of all, there is the situation of users logging into a text console or remote tty via ssh. What gets run when those users login is usually controlled by their shells rc files and the system shell profiles. Then there is the graphical environment case, which is ...


7

POSIX is the Portable Operating System standard. It describes certain utilities, APIs, and services a compliant operating system must provide to software (for example sockets, file I/O and threading) along with conventions on how these should be called from a program. The idea is that a program written for one POSIX-Compliant OS would be easier to port to ...


6

When seeing cat hugeregularfile.txt > /dev/null, the shell is not allowed to believe that the action is useless — cat is not part of the shell and could do anything at all in theory, and also in practice. For example, the user may have renamed the executable rm to cat, and suddenly the line performs externally observable behavior, i.e., removing ...


5

Writing a shell script in a specific shell means having that shell installed. The only standard is to have csh and sh installed over all Unix variants. So, if you wanted your script to run on Solaris, *BSD, and GNU then you would have to write it in, say, the Bourne shell. However, most Unix commands have different syntaxes under different ...


5

In addition to the web links, you can also install the POSIX man pages, e.g. on a Debian-like system they are available as manpages-posix-dev package. Then you can lookup the POSIX version of say - the read system call - via: $ man 3p read Or the mv command $ man 1p mv Just add a p to the usual man page section number. 'to get a better understanding ...


5

By "globally", do you mean for all users? I put my path modifications in ~/.profile, as it affects X applications as well. If you want it in the system profile it's probably best to modify /etc/profile


5

There is a set of commands most if not all Linux distributions, and for that matter, also Unix distributions will provide. These are the mandatory commands specified by the POSIX standard. The commands you cite (cd, mkdir, ls, echo, grep, sed, awk, ping etc.) are all part of it.


5

On non-embedded Linux systems, you can generally count on most GNU utilities: coreutils bash findutils (at least find and xargs, not necessarily locate and updatedb) grep gzip sed tar plus the util-linux suite and the procps suite. Note that /bin/sh is not always bash, it can be a shell with less features such as one of the multiple forks of ash. The ...


4

In addition to dash and posh, there's bournesh (or bsh), the Heirloom Bourne Shell, that can be used to detect Bashisms. The Heirloom Project also includes "The Heirloom Toolchest", a collection of more than 100 standard Unix utilities (which could serve as a starting point for comparing command line options).


4

Arch is a minimalistic linux distribution, so normally there are no other special configuration files which are getting included in some strange placces, modified by system configuration wizards. /etc/profile is the right place to do this for a system wide configuration. This file is intended to be used for ALL common Bourne-compatible shells. Shell ...



Only top voted, non community-wiki answers of a minimum length are eligible