On Thu, Feb 28, 2013 at 09:55:01AM -0700, Bob Proulx wrote:
Who still remembers when if the exec(2) failed then the shell
examined the first character. If it was a '#' then shell ran the file
through csh. If ':' then through ksh. If neither then sh. This may
have been a local hack though.
On Mon, May 21, 2012 at 03:46:00PM -0400, Chet Ramey wrote:
Posix says that ranges work the way you are used to if you force the
traditional ordering using the `C' or `Posix' locale. Take a deep
breath and use LC_ALL=C in your scripts to avoid depending on whatever
your OS uses as the
On Wed, Dec 28, 2011 at 01:47:47PM -0500, Greg Wooledge wrote:
On Wed, Dec 28, 2011 at 07:44:40PM +0100, ck...@web.de wrote:
(xclock )
Yet xclock closes when the script exits because it receives a SIGHUP.
If you want a process to ignore a signal, you should either use nohup(1),
or
Bob Proulx wrote:
+1 vote on getting the parameters listed with a leading dollar sign.
The individual single character is difficult to search for but the
combination of $@ and so forth for the others is a useful search
string. I have often wanted the manual to include the $@
combination
Andreas Schwab wrote:
Sven Mascheck writes:
I haven't become familiar with the info format until now.
As acceptable workaround even for long manuals I usually
There is an index entry for @, [...]
I was probably too short, I meant searching a tradititional man page.
Sven
On Mon, Jul 18, 2011 at 10:46:19AM -0400, Steven W. Orr wrote:
On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
printf 'foo\nbar\n'/dev/udp/localhost/4242
and two packets are sent, one per line. If the aim is to send a string
of data in one packet this causes problems.
Using
On Mon, Feb 28, 2011 at 07:47:12AM -0430, Andres Perera wrote:
unquoted assignments should not apply IFS to $@
BTW, out of plain curiosity http://www.in-ulm.de/~mascheck/various/ifs/
lists some existing implementations.
On Mon, Oct 11, 2010 at 08:12:23AM -0400, Greg Wooledge wrote:
On Sat, Oct 09, 2010 at 12:06:21AM +0200, Sven Mascheck wrote:
On Mon, Sep 20, 2010 at 09:14:15AM -0400, Greg Wooledge wrote:
unset array
while IFS= read -r -d '' f; do array+=($f); done \
(find . -name '*.c' -print0
On Sat, Oct 09, 2010 at 12:06:21AM +0200, Sven Mascheck wrote:
find . -type f -name '*.c' -exec sh -c 'vi $@' find-sh {} +
PS (still offtopic): vi was not the original example, it came as
illustration. But sh -c '' is only useful if you still have to process
the filenames somehow (which I
On Mon, Sep 20, 2010 at 09:14:15AM -0400, Greg Wooledge wrote:
The disadvantage of -exec is that if you wanted to do something within
your shell (putting the filenames into an array, incrementing a counter
variable, etc.), you can't. You're already two processes removed from
your shell.
On Thu, Jul 08, 2010 at 10:23:00PM +0200, Thomas Hafner wrote:
Bash Version: 3.1
Patch Level: 17
Description:
See this shell code:
: $( #
)
bash-3.2 has this fixed.
In case you want to exploit further, you might find
Peng Yu wrote:
Is there a way to configure bash such
that there is not a limit like this?
/bin/bash: Argument list too long
bash is not to blame - it reports an error message from the kernel.
You seem to have called bash (or some other command?) with too many
arguments, exceeding your
On Fri, Dec 11, 2009 at 12:31:49PM +, pk wrote:
Marc Herbert wrote:
is_file3()
{
for f
do
[ -e $f -o -L $f ] return
done
return 1
}
You might also want to enable dotglob to catch hidden files...
empty=yes
for i in .?* *
do
Chris F.A. Johnson wrote:
This has been discussed more than once in c.u.s; check the
archives.
and that's why we better discuss it here now?
On Mon, Nov 09, 2009 at 02:43:43PM -0500, Chet Ramey wrote:
[...] confusing Solaris (quite recent SVR4-like shell)
with Ultrix (sh: V7-like shell without functions
Solaris's default shell, though more modern than the old Ultrix one,
is not Posix-conformant.
Gosh, my recent ('88) is
Chet Ramey wrote:
Linda Walsh wrote:
A previous note had me wondering why the syntax for using
curly braces to group expressions wasn't able to be the same as
using 'paren's.
Braces are reserved words. Parentheses are operators. Blame
Steve Bourne.
I wonder about the motivation, or
On Tue, Aug 04, 2009 at 02:04:31PM -0500, Mike Coleman wrote:
This scenario is not something that will happen accidentally, since
there's really no way to SIGSTOP the child without doing it from
another shell, so the prospect of a user ending up in front of a
hung shell doesn't seem like that
On Wed, Mar 11, 2009 at 10:11:22PM -0400, Chet Ramey wrote:
(bash exits, leaving some-command running)
How could you run daemons from the command line otherwise?
I'm curious, what do you mean with daemons here?
I'd expect real daemons to detach from the terminal and create
a new session /
On Wed, Feb 25, 2009 at 01:20:50PM -0500, Mike Frysinger wrote:
seems there's a way to get bash to report exit values greater than 255 ...
you will find the special error values
in shell.h, for instance
#define EX_SHERRBASE256 /* all special error values are this. */
#define
PS: Traditional shells (only) are too offtopic on bug-bash;
I guess, we better limit to bug-autoconf.
Eric Blake wrote:
According to Stephane Chazelas on 10/29/2008 3:32 AM:
: stdout stderr
For shell portability, I'll write the first line as
: stdout
: stderr
though.
Why?
It fails on old Ultrix sh, which can't redirect the same fd more than once
in a single statement. But
Eric Blake wrote:
Read the POSIX rationale:
http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap02.html
| [...] While the newer $() form can process
| any kind of valid embedded script, the backquoted form cannot handle
| some valid scripts that include backquotes. For example, these
Eric Blake in [EMAIL PROTECTED]:
several platforms, including Solaris' /bin/sh, still do not
parse ( in case patterns even today, so it is certainly
not portable if you don't have access to a POSIX shell.
Even if they parsed it, it wouldn't be portable,
because no traditional Bourne shell
23 matches
Mail list logo
