+ -
addition, subtraction
Cheers,
-Sven
--
PS: As I am not subscribed to bug-bash, please CC me on replies
to the list.
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
t; your OS uses as the default.
I'd suggest to use "only" LC_COLLATE=C to keep other important features
like e.g. printability (LC_CTYPE) or localized messages (LC_MESSAGES).
Or has anybody ever noticed problems with this approach?
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
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
ore than seems reasonable, sometimes. A pretty bad example was
in an older rationale, ISO/IEC 9945-2:1993, E.3.6.3, p. 833:
"the author of the KornShell has agreed to make the appropriate
modifications to do so"
Sven
as removed it, but
bash doesn't know it's gone. The new shell you executed starts with an
empty hash. You can use hash -r to force bash to forget it.
Sven
--
Sven Wegener
Gentoo Developer
http://www.gentoo.org/
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
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,
dmins can save a lot of
time if they don't need to explore it themselves.
Repeat-By:
run "man bash", search for "cleanup", scroll one line up.
Fix:
Dunno how manpages are made, but I guess it's easy :-)
Yours sincerely,
Sven
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
data will be executed
in a subshell and can't set variables of the calling shell. This is just
how pipe'ing works. You can do an hackish workaround like:
evalfunc_stdin B test < <( echo )
to execute the function in the current shell and receive input on stdin.
Cheers, Sven
--
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
processes that are
still running. The backgrounded true will exit nearly immediately and
wait can't wait for it because it has already terminated.
Looking at the source it proves me right for wait without any arguments.
"But wait without any arguments means to wait for all of the shell&#
On Mon, Nov 28, 2005 at 11:30:29AM -0500, Chet Ramey wrote:
> Sven Wegener wrote:
>
> > The debugging_mode check should be removed, or the info manual and man
> > pages need to be adjusted to represent the current behaviour.
>
> The documentation has already been correc
and man
pages need to be adjusted to represent the current behaviour.
Cheers,
Sven
--
Sven Wegener
Gentoo Developer
http://www.gentoo.org/
pgphDUh9LYOnK.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org
nation.
How can I solve the problem from the terminal side (xterm or whatever)?
Or a fairer question: where should I pose the above question?
Greetings
Sven
pgpXGzB5Mre5p.pgp
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
> Please read item E11 in the Bash FAQ.
Yes, I read and tried "shopt -s checkwinsize" before I asked this question.
Unfortunately, the problem persists.
Just to be sure: I meant that the old information in the xterm window is
not extended by the characters that should be visible aga
ution?
Greetings
Sven
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
41 matches
Mail list logo
