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 thou
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 def
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
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
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 "$@"
> combina
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 Wed, May 04, 2011 at 03:40:01PM -0500, Rafael Fernandez wrote:
> [...] I am used to the behavior of sh on NetBSD which does not require
> enclosing positional parameters. I believe it is adequately expressed in the
> manual page,
The NetBSD manpage documents it as usually implemented. I guess
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 Fri, Dec 31, 2010 at 12:20:38PM -0800, chengiz wrote:
> On Dec 31, 12:20 pm, Sven Mascheck wrote:
> > (see also http://lists.gnu.org/archive/html/bug-bash/2008-01/msg00049.html)
> > [...]
>
> I dont see how that's related - I dont doubt you that the fix to this
On Dec 30, 12:59 pm, chengiz wrote:
> > In an earlier version of bash (3.2), the following works
> > ls `pwd`/ (expands pwd).
> >
> > In bash 4.1 it does not. Am I missing a setting or something?
> > Thank you.
This changed with bash-3.2.37
"Bash inappropriately evaluates command substitutions
On Mon, Oct 11, 2010 at 09:02:25AM -0400, Greg Wooledge wrote:
> Also, if you truly must have them all in one invocation, it may
> be better to fail and get a nice friendly error, than to have the
> command run with only a subset of the files.
Good point, thanks.
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+=(&
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 hav
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 Fri, Sep 24, 2010 at 11:28:50AM +0200, Sven Mascheck wrote:
> > test x && test y || test z
> which, on the other hand, people sometimes use as replacement for
>if test x; then test y; else test z; fi
> although it behaves differently. In the former, test z i
On Fri, Sep 24, 2010 at 09:22:50AM +0100, Marc Herbert wrote:
> [...]
> For longer conditions brackets are easier to "parse"; the reader has no
> doubt where it ends.
>
> By the way I wonder if this makes any difference to the actual parser.
>
> On the other hand some people explain that long co
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
http://www.in-ulm.de/~mascheck/various
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 ke
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 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 i
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
On Mon, Nov 09, 2009 at 09:10:02AM -0500, Greg Wooledge wrote:
> On Mon, Nov 09, 2009 at 03:49:09PM +0200, Ciprian Dorin, Craciun wrote:
> > P.S.: The fact that some features of Bash, mainly `set -e`, which
> > should be a safety-net for scripts, is "unpredictable" is not so very
> > reassurin
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 motiva
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
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 E
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
Stephane Chazelas wrote:
>> According to Scott Moser on 10/30/2007 7:12 AM:
>>> x=$(cat <<"EOF"
>>> bad' syntax
>>> EOF
> Note that it's the same as for
>
> $(
> case a in
>a) ...
> esac
> )
These are already on the todo list. See
<[EMAIL PROTECTED]>.
> I thought the POSIX
> case a i
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,
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
31 matches
Mail list logo
