echo $x
done
That does not work as desired, nor does putting "$XXX" within quotes do
the trick (obviously). Is there a way?
Bob
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
On Sat, 18 Mar 2006 20:44:17 -0500, Paul Jarc wrote:
> Bob <[EMAIL PROTECTED]> wrote:
>> XXX='a "b c" d'
>> for x in $XXX ; do
>> echo $x
>> done
>
> XXX='a "b c" d'
> eval "set $
On Sun, 19 Mar 2006 03:02:51 +, Bob wrote:
> On Sat, 18 Mar 2006 20:44:17 -0500, Paul Jarc wrote:
>
>> Bob <[EMAIL PROTECTED]> wrote:
>>> XXX='a "b c" d'
>>> for x in $XXX ; do
>>> echo $x
>>>
o yes; else echo no; fi
ed> q
if true; then echo yes; else echo no; fi
yes
> C-d bash: syntax error: unexpected end of file
exit
Just another rendition of the same thing.
Bob
n some detail here:
http://lists.debian.org/debian-user/2007/08/msg00022.html
And more recently with a little more rationale here:
http://lists.debian.org/debian-user/2008/04/msg02554.html
Bob
PROMPT_COMMAND='echo -ne "\033]0;${us...@${hostname}:${PWD/$HOME/~}\007"'
;;
esac
Then add something like this for your adjusted PS1 prompt.
PS1='\n\[\033[1;31m\]...@\h:\w]\$\[\033[0m\] '
That leading \n gives me pause though...
Bob
Roger wrote:
> # See ionice manfile - give high priority to Bash
> ionice -c 2 -n 0 -p `echo $$`
You don't need to use backticks to echo out the value of $$. Just use
it directly.
ionice -c 2 -n 0 -p $$
Bob
o
clear characters but not to clear the characters from the previous
command. That information does not exist. Adding a way to track that
information is not easy and would introduce many problems and errors.
Therefore what you are asking for probably is unlikely to ever be
implemented.
Bob
ion currently attached to C-l. Then
it would work as you describe. I have never done that, don't know
how, but it seems reasonable to me. :-)
Bob
ly not a simple thing to do at
all. This is really a much harder problem than you think it is and
isn't something that can be fixed in bash. The best result is simply
learning to avoid the problem.
Bob
people would consider at least one of those in that set a
real programming language. :-)
Bob
Marc Herbert wrote:
> Bob Proulx a écrit :
> > The shell isn't the only one that introduces a security vulnerability
> > on most systems when setuid. All interpreters are the same in that
> > regard. On systems where you shouldn't suid scripts then you
> >
ed. That is why there have been so many successful attacks
in the past. There isn't any magic sauce to make all of the
complication go away. Attackers are as clever as you. It is a
classic battle between armorer and weapons maker.
Bob
There are two types of complicated programs. Those that w
"72057594037927936*128" | bc -l)
9223372036854775808
Bob
Stephane CHAZELAS wrote:
> Bob Proulx wrote:
> [...]
> > Your expressions above are overflowing the value of your system's
> > maximum integer size. You can read the system's maximum integer size
> > using getconf.
> >
> > $ getconf INT_MAX
>
eserverhost date -R)"
Push:
date -R | ssh remoteclienthost date --date='"$(cat)"'
The --date= just prints the time. After you are happy with the
results change --date= to --set= which actually sets the system clock.
I think it would be much more productive use of your resources to
enable ntp instead.
Bob
ote octal. In octal the valid digits are 0-7 with 8
and 9 outside of the octal range.
Bob
nd a
severe bug if it did.
Are you forgetting to put your desired configuration into ~/.bashrc
where it is loaded when bash starts?
Are you forgetting to put
source "$HOME/.bashrc"
into your ~/.bash_profile where it will source your .bashrc when you
log into your account?
Bob
me you are running bash
otherwise.)
Is the behavior you observe any different for this case?
$ bash -c 'while true; do /bin/true || exit 1; done'
Or different for this case?
$ bash -e -c 'while true; do /bin/true; done'
Bob
Oleg Nesterov wrote:
> Bob Proulx wrote:
> > Is the behavior you observe any different for this case?
> > $ bash -c 'while true; do /bin/true || exit 1; done'
> > Or different for this case?
> > $ bash -e -c 'while true; do /bin/true; done'
>
bash -c 'while true; do /bin/true || exit 1; done'
Bob
T}="DEFAULT";kill(INT,$$);}; sleep' || exit 1
echo "Hehe, I am going to sleep after ^C"
sleep 100
exit(0);
Does this get interrupted after one SIGINT now that it isn't being
caught and ignored?
To be clear I am simply trying to make sure the test cases are not
themselves creating the problem.
Bob
lls
parse the command line. Quoting is then much simplified.
Bob
nt something like:
_CRed="$(echo -en "\033[31m")" #Red
_CRST="$(echo -en "\033[0m")" #Reset
_CBLD="$(echo -en "\033[1m")" #Bold
export _prompt_open=""
export _prompt_close=">"
[[ $UID -eq 1000 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="#$_CRST"
}
export PS1='\[${_prompt_open}\]$(pwd "$PWD")\[${_prompt_close}\] ';
But I didn't test the above.
Bob
ll of the discussion around the \[...\] has been about.
Unless I have completely misunderstood your problem but I don't think
so.
Bob
tly using.
_CRed=$(tput setaf 1) #Red
_CRST=$(tput sgr0) #Reset
_CBLD=$(tput bold) #Bold
_prompt_open=""
_prompt_close=""
_prompt=">"
[[ $UID -eq 0 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt_close="$_CRST"
_prompt="#"
}
PS1='\[$_prompt_open\]$(pwd "$PWD")$_prompt\[$_prompt_close\] ';
Bob
Greg Wooledge wrote:
> red=$(tput setaf 1) bold=$(tput bold) reset=$(tput sgr0)
> PS1='\[$red\]\h\[$reset\]:\[$bold\]\w\[$reset\]\$ '
>
> I tested that. It works.
Nicely cleaned up!
> PS1='\h:\w\$ '
For what it is worth I use something similar:
PS1='\u@\h:\w\$ '
Bob
~-/. is no equal to $PWD
No. But it is similar to $OLDPWD which is what Greg had written about.
Bob
SPLAY" ] && open -W /tmp/$$.html
ls /tmp/$$.html
rm -f /tmp/$$.html
I do not have a Mac and have no way to test the above but the
documentation leads me to believe that it will work.
Bob
nd permissions this is the safer course of action.
Bob
ttp://www.in-ulm.de/~mascheck/various/shebang/
Bob
it needs bash explicitly or you could use portable only
constructs and continue to use /bin/sh. Personally I use bash for my
command line but /bin/sh and portable constructs for shell scripts.
Bob
is a b c
>
> What would be script to acheive this functionality
You will need to quote the filename to preserve the spaces.
$ cp "a b c" /some/other/directory/
Bob
enable_ext4='no'
I seem to recall a similar command on Red Hat based systems but off
the top of my head the details escape me.
Bob
r do you know if the next character that has no
yet been generated yet will be a newline? Should it wait a timeout
until characters have stopped appearing?
It really isn't a problem that can always be solved perfectly in every
case.
Bob
rocess,
Yes, but it is a fork(2) of the parent shell and all of the variables
from the parent are copied along with the fork into the child process
and that includes non-exported variables. Normally you would expect
that a subprocess wouldn't have access to parent shell variables
unless they were exported. But with a subshell a copy of all
variables are available.
Bob
;}
foo="bar"
( printfoovar )
#!/bin/sh
printfoovar() { eval echo \$$foo ;}
bar="hello"
foo="bar"
( printfoovar )
Bob
and (...) is back to the
original discussion of the thread that subshells have access to
copies of all parent variables including variables that were not
explicitly exported.
Hope that helps to clarify things.
Bob
ddresses are useless if not known and once known
cannot be hidden. But just the same I have experienced that people
complain vehemently if you don't mangle addresses in the web archive.
And then problems such as the above occur. Sigh. It is impossible to
please both sets of people.
Bob
ery=exit&apropos=0&sektion=3&manpath=2.9.1+BSD&format=html
Now you might argue that -1 is always going to be all ones in two's
complement. Sure. But traditionally it has always been unsigned.
Bob
Linda Walsh wrote:
> How about portable code using:
>
> (exit -1); return
>
> It's ugly, but would seem to be the portable/official way to
> do this.
Exit codes should be in the range 0-255.
Bob
Linda Walsh wrote:
> Bob Proulx wrote:
> >Exit codes should be in the range 0-255.
> ---
> I suppose you don't realize that 'should' is a subjective opinion that
> sometimes has little to do with objective reality.
Sigh. Okay. Keep in mind that turn about
7;
Sure it doesn't handle whitespace in filenames but what classic AIX
Unix symlink would have whitespace in it? :-)
Bob
uot;)
physdir=$(cd "$dir"; pwd -P)
realpath=$(cd "$dir"; ls -l "$base" | awk '{print$NF}')
echo "$physdir/$realpath" | sed 's|//*|/|g'
exit 0
Again, another very quick and partial solution. But perhaps something
good enough just the same.
Bob
ally don't use a pattern expression.
But I agree it is another way to go. But it is easier to say
whitespace is bad in filenames than to say whitespace is bad and oh
yes you can't have "->" in there either. :-)
Bob
cd $(dirname "$path"); pwd -P)
base=$(basename "$path")
> echo "${dir%/}/${base}"
> fi
> }
And of course those are just suggestions and nothing more. Feel free
to ignore.
Note that there is a recent movement to change that dash greater-than
combination into a true unicode arrow graphic emited by 'ls'. I think
things paused when there were several different bike shed suggestions
about which unicode arrow symbol people wanted there. I haven't seen
any actual movement for a while and I think that is a good thing.
Bob
/programming/stdio_buffering/
And the 'stdbuf' command the came out of it.
http://www.gnu.org/software/coreutils/manual/html_node/stdbuf-invocation.html#stdbuf-invocation
Bob
Greg Wooledge wrote:
> Linda Walsh wrote:
> > Bob Proulx wrote:
> > >This may be a good point to mention this reference:
> > >
> > > http://www.pixelbeat.org/programming/stdio_buffering/
>
> > Does it only work with gnu programs? I.e. how would
in is
making good use of it in the Cygwin environment for the same purpose.
Therefore the standards say that two leading slashes are significant
and are handled specially. It might be a network path. But three or
more leading slashes are not significant and anywhere else in the path
multiple slashes are not significant.
Bob
T
isdst=1 gmtoff=-21600
US/Mountain Sun Nov 7 07:59:59 2010 UTC = Sun Nov 7 01:59:59 2010 MDT
isdst=1 gmtoff=-21600
US/Mountain Sun Nov 7 08:00:00 2010 UTC = Sun Nov 7 01:00:00 2010 MST
isdst=0 gmtoff=-25200
See this FAQ entry for more information:
http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Bob
> How do I get rid of the delay. I want it to release the terminal
> immediately.
Does your PATH contain directories on NFS or other networked
fileservers? If so then those are typical sources of delay.
To easily see your directories in PATH:
echo $PATH | tr : "\012"
Bob
ame):
/"'
ssh -n server2 'tail -f /var/log/syslog | sed --unbuffered "s/^/$(hostname):
/"'
You might consider applying the commands as standard input instead. I
think it is easier to avoid quoting problems that way.
echo 'tail -f /var/log/syslog | sed --unbuffered "s/^/$(hostname): /"' | ssh
-T server1
Bob
xpect a new
question about how to start and restart this connection automatically.
(Am I right? :-) Instead please investigate using one of the syslog
programs that does exactly that already. See for example 'rsyslogd'
which supports remote logging.
Good luck!
Bob
h the
development of the shell.
I am going to send an answer to you but in another message. I will CC
the help-gnu-utils mailing list. Let's move any discussion and
followup to help-gnu-utils instead of here.
Bob
Peng Yu wrote:
> Current, bash doesn't do command completion between do and done (for loop).
> I'm wondering if this feature can be added.
Of course bash does do command completion between do and done. Can
you give an exact example test case? On what version of bash?
Bob
out of
sync with the current action point.
Of course I was trying filename completion. The simpler case is:
while false; do l
But other completions do work fine.
while false; do ls --so
while false; do ls ~/.ba
As a workaround you can force command completion using 'C-x !' and
'M-!'.
Bob
y to /dev/console is a little harsh. You might
consider using the 'logger' program and writing to the syslog instead.
Your script makes me think that you might be using an NFS automounter
and trying to correct nfs client problems. (shrug)
Bob
DJ Mills wrote:
> Bob Proulx wrote:
> > sh -x ./scripttodebug
>
> I'm guessing you mean bash -x, not sh -x. Two different shells.
It is a bash list so I probably should have said bash just to be
politically correct. But the script doesn't use any bash specific
constr
..@gnu.org.
And in a similar way I added the following description to help-bash.
Bash is the GNU Project's Bourne Again SHell. This list is for
asking questions about bash and shell programming. Also available
is htlp-gnu-ut...@gnu.org for general questions about the shell
utilities.
Any comments?
Bob
one is curious as to what text we have been talking
about it is the text that shows up here, and related places:
https://lists.gnu.org/mailman/listinfo/bug-bash
Bob
>> "$1"/.accesstest
Or you could use a helper command. Using a different program other
than 'touch' may cause it to emit a better error message.
Bob
d your troubles. But that isn't
the scientific method.
http://en.wikipedia.org/wiki/Scientific_method#Elements_of_scientific_method
> Not doing anything with NFS mounting thankfully. It's a RAID array on
> a NAS device which is typically used for SMB / CIFS network mount.
Your system is mounting it using an SMB mount? Then perhaps your
network protocol layer is causing trouble. I think a bug in the SMB
layer is much more likely.
Bob
the system either.
If you want bash to be reduced to a smaller size try exec'ing itself
in order to do this.
$ exec bash
That is my 2 cents worth plus a little more for free. :-)
Bob
Timothy Madden wrote:
> Is the 'htlp-gnu-ut...@gnu.org' list on the help-bash info page
> meant to be 'help-gnu-ut...@gnu.org' (note 'help' instead of 'htlp'
> in the list name) ?
> Can the list info on the web be updated ?
Thanks for reporting that error. Fixed now.
Bob
was a way to negate the expression without using a '!' which didn't
exist in that shell. An 'if' could operate using the 'else' clause.
But there wasn't any other way to do it in a while loop. The addition
of '!' to the language was one of the best features. IMNHO. I use it
all of the time now.
Bob
'. They are
similar. But then instead of using 'ps aux' BSD style try not
printing the full path by using 'ps -e'. You are matching your own
grep becuase it is in the argument list.
Then this can be made smarter by simply matching it as a string
instead of as a pattern.
ps -e | awk '$NF=="crond"'
ps -e | awk '$NF=="crond"{print$1}'
Bob
signature.asc
Description: Digital signature
ng 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 instead of just the "@" name.
Bob
ies separated by colons "#*:" will
match and therefore remove the first element of the PATH.
$ foo=one:two:three
$ echo ${foo#*:}
two:three
And using two pound signs "##" would match the loggest pattern and
remove all up through the last one.
$ echo ${foo##*:}
three
Bob
uot;
device such as a serial port or tty or other. Assuming I recall this
correctly of course.
Bob
tapczan wrote:
> #!/bin/bash
> echo $-
>
> Execution:
>
> # ./a.sh
> hB
>
> There is no 'i' so the session is non-interactive?
> It was invoked from interactive.
> Am I missing something?
Shell scripts are not interactive. So what you are seeing above is
correct.
Bob
tapczan wrote:
> Bob Proulx wrote:
> > Shell scripts are not interactive. So what you are seeing above is
> > correct.
>
> So, is there any way to test if script (a.sh) was invoked from interactive
> session (human) or not (e.g. from cron)?
I usually check if the standa
}}}
Seems reasonable to me. In that context the bracket isn't special in
any way and is just another character in the string. Just like this:
$ echo
Bob
e a syntax error in other
> > shells.
>
> I was going for || exit "Doomsday" i,e. 666 = 999 = Apocalypse.
Yes. But... As we all know exit codes are only eight bits and that
limits you to 0-255 only! Anything else and you have "jumped the
tracks" with implementations doing implementation defined things.
Maybe one of them will invoke the game of rogue! :-)
Bob
the resulting config.log file.
configure:4710: checking for special C compiler options needed for large files
configure:4805: result: no
configure:4811: checking for _FILE_OFFSET_BITS value needed for large files
...
configure:4922: result: 64
...
ac_cv_sys_file_offset_bits=64
Bob
ve been trying to train myself out of that
habit for the last few years. Now I always use lower case variable
names. (For example tmpdir, which shouldn't collide.)
So for this I would say the script should use lower case names instead
of upper case names.
Bob
lly allocating all memory, is inefficient. Whereas using grep as a
filter to reduce that memory to 89 bytes is of course more efficient.
I wrote a response on a similar issue previously. Instead of posting
it again let me post a pointer to the previous message.
http://lists.gnu.org/archive/html/bug-bash/2011-11/msg00189.html
Bob
And lastly I will comment that you are doing quite a bit inside of an
interrupt routine. Typically in a C program it is not safe to perform
any operation that may call malloc() within an interupt service
routine since malloc isn't reentrant. Bash is a C program and I
assume the same restriction would apply.
Bob
within the standard. Any previously standard conforming
and well behaved script would still be standard conforming and well
behaved. That being the whole point of the POSIX standard I see this
as a good thing.
Bob
ppen. But
if libc isn't going to do it then it is beneficial if projects do it
themselves outside of libc. Eventually in the future when libc
addresses the problem then those hacks can be removed.
Bob
etail and pointed a reference. I am very happy to
see things progress in that direction. Thanks!
Bob
ally limited by the
system policy.
Bash here in this context is simply running within the operating
system limits imposed by the policy of the system as reflected in the
stack size limits.
Bob
Unless you are set up to debug the resulting
core then it isn't useful. Also dumping a large core over the network
to an NFS mounted directory, an action that takes place in the kernel
and on at least some systems is not interruptable, a few times will
convince you that you don't want to wait for it.
Bob
hen you would.
You might argue that the error message in that case could be more
friendly. That would be a bash specific discussion and perhaps even a
useful one. See 'man 3 setlocale' for more details. On my system
locale files are stored down /usr/share/locale/* paths.
Bob
n, most people would consider that bad.
This is a reductio ad absurdum ("reduction to absurdity") argument
that doesn't apply here. The linux kernel was not crashing. This is
off the topic.
Bob
ssage?
Or are you suggesting that bash should specify its own stack area so
as to avoid the system stack size limitation?
I could see either of those first two solutions being reasonable.
Bob
ch stack space as you can.
Well... There is the gnulib c-stack module:
http://www.gnu.org/software/gnulib/MODULES.html
c-stack Stack overflow handling, causing program exit.
Bob
> Sending TERM signal to the subshell doesn't make "submain_cleanup()"
> to be called.
And it does in ksh93. Hmm... And it does if I comment out the line
"trap main_cleanup EXIT". It seems to only set the trap if no trap
handler was previously set.
Bob
value is sticky and will persist through upgrades until changed.
Bob
Stefano Lattarini wrote:
> Hi Bob, thanks for the tips. However ...
>
> Bob Proulx wrote:
> > Stefano Lattarini wrote:
> >> Anyway, my /bin/sh is bash ...
> >> $ ls -l /bin/sh
> >> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash
> >>
called as /bin/sh Debian patched it to not drop
privileges?
Or:
3. ??
Bob
ays then the only option for you is to simulate
them. That isn't too difficult and if you search the web there are
many different implementations with the biggest difference being
whether ordering matters or not.
Bob
y
file.
newgrp group1 < other-script-file
Or you might consider using 'sudo' or 'su' for that purpose too.
Bob
option causes the export property to be
removed from each name. If a variable name is followed
by =word, the value of the variable is set to word.
export returns an exit status of 0 unless an invalid
option is encountered, one of the names is not a valid
shell variable name, or -f is supplied with a name that
is not a function.
Bob
age here] operator precedence table. (If you looked over at your
copy next to you then you know what I am talking about.)
Bob
been absorbed yet.
Just like:
grep -r PATTERN
Has replaced:
find . -type f -exec grep PATTERN {} +
And therefore they don't know how to write other directory traversal
tasks either.
find . -type f -exec sed -n '/PATTERN/s/THIS/THAT/gp' {} +
Bob
7;set -o physical' everywhere to have consistent behavior.
The evil truth is better than a good lie.
Bob
p://www.cons.org/cracauer/sigint.html
Since this is being asked as a general question this would be a better
topic to start discussing first on on the help-bash mailing list. As
currently stated it is too non-specific to be a bug report to
bug-bash.
Bob
hell was constructed specifically to be as strictly
conforming to posix as possible. (Making it somewhat less than useful
in Real Life but it may be what you are looking for.) It is Debian
specific in origin but should work on other systems.
http://packages.debian.org/sid/posh
http://anonscm.debian.org/gitweb/?p=users/clint/posh.git;a=summary
Bob
$ cat >/tmp/trial <<'EOF'
#!/bin/posh
echo "Hello from posh"
exit 1
EOF
$ chmod a+x /tmp/trial
$ /tmp/trial
Hello from posh
$ echo $?
1
I see no error when using 'exit 1'. Other than the expected exit
code. What am I missing?
Bob
#!/bin/bash as the interpreter. Scripts
that specify #!/bin/sh and use bash specific features will fail. As a
local option the local admin may change the /bin/sh symlink from dash
to bash and run scripts from other systems that include bash features.
But that isn't by default. However it is a useful option for people
stuck needing to run code that isn't cleanly written.
Bob
1 - 100 of 510 matches
Mail list logo
