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 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 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 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, 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
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
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 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
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 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
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
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,
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:
> 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
PS: Traditional shells (only) are too offtopic on bug-bash;
I guess, we better limit to bug-autoconf.
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
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 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
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 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
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 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
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?
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
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
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 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 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 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, 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 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.
31 matches
Mail list logo
