On Wed, Mar 27, 2013 at 02:37:16PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> >>> Array variables may not (yet) be exported.
> > Associative arrays can't be exported either.
> Yeah, but they seem to get propagated anyway, I must save it somewhere
On Fri, Mar 29, 2013 at 12:41:46AM -0700, Linda Walsh wrote:
> include was designed to search the path for functions that
> are relative paths. While the normal sourcepath allows searching for
> filenames on the search path, I don't believe (please correct if I am wrong
> and this works now,
On Fri, Mar 29, 2013 at 03:11:07PM +0100, John Kearney wrote:
> Actually I've had trouble
>
> IFS=: read -ra paths <<< "$PATH"
>
> and embedded new lines.
A directory with a newline in its name, in your PATH? Terrifying.
> I think this is better
> find_file() {
> local IFS=:
> for dir
On Fri, Mar 29, 2013 at 04:10:22PM +0100, John Kearney wrote:
> consider
> dethrophes@dethace ~
> $ read -ra vals -d '' <<< $'lkjlksda\n adasd\n:sdasda:'
>
> dethrophes@dethace ~
> $ echo ${vals[0]}
> lkjlksda
You forgot to set IFS=: for that read.
imadev:~$ IFS=: read -ra vals -d '' <<< $'lkjlk
On Mon, Apr 01, 2013 at 03:16:07PM +0300, Hemmo Nieminen wrote:
> Description:
> Currently it seems to be impossible to e.g. print "-n" with the
> builtin
> echo witout any extra characters.
You should use printf instead. The echo command is a historical artifact
which cannot be
On Thu, Apr 04, 2013 at 02:26:34AM -0500, Dan Douglas wrote:
> > On Wed, Feb 6, 2013 at 11:30 AM, konsolebox wrote:
> > > Hi. I was wondering if we could add a builtin where we could use it as an
> > > alternative for assigning values to a parameter. And thought of a builtin
> > > name called setv
On Thu, Apr 04, 2013 at 09:11:49PM +0800, konsolebox wrote:
> On second thought I think we still need the function since for declare -n:
>
> a) Reference variable could not be an array.
I'm not sure what you mean. But namerefs may point to arrays or
associative arrays in the caller's context.
A
On Thu, Apr 04, 2013 at 09:17:00PM +0800, Chris Down wrote:
> Perhaps my reply here[1] can help out. Only looked briefly, but it seems it
> could at least eliminate the calls to eval (although it doesn't support some
> more rare tilde expansions).
>
> Chris
>
> 1: http://lists.gnu.org/archive/htm
On Thu, Apr 04, 2013 at 10:56:35AM -0700, Andy Valencia wrote:
> Description:
> If one has a file "data.txt" and a shell script "x", it used to
> be possible to run this with "sh x dat" and have the file argument
> completed to "data.txt". As of Debian Wheezy update completion
>
On Thu, Apr 04, 2013 at 08:51:19PM -0500, Mara Kim wrote:
> The biggest benefit is that it is just plain easier than managing a
> directory of symbolic links on your own. I am extremely lazy.
>
> Here is an example use case. At the end of a work day, I like to bookmark
> the folder I am working in
On Fri, Apr 05, 2013 at 09:15:10AM +0800, konsolebox wrote:
> The only thing left here is that we can't have error control like when we
> are to create generally shared library scripts e.g.:
>
> function lib_something {
> declare -n VAR=$1 &>/devnull || { # error message is not suppressed
>
On Sun, Apr 07, 2013 at 01:13:09AM -0700, Linda Walsh wrote:
> > getent passwd 'Domain Administrator'
> Domain Administrator:x:500:18:Domain Admin accnt:/home/root:/bin/bash
getent(1) is fine where it's available, but it's not a standard tool,
so you can only use it on systems that have it.
If on
On Mon, Apr 08, 2013 at 10:32:40AM -0400, Chet Ramey wrote:
> One clarification: a variable is unset unless it has had a value assigned.
> There might be some placeholder there with some type information, but the
> variable is unset. There might be some inconsistencies in how bash treats
> such va
On Mon, Apr 08, 2013 at 05:13:46PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> > getent(1) is fine where it's available, but it's not a standard tool,
> > so you can only use it on systems that have it.
> Have you encountered it on other linux systems?
It i
On Tue, Apr 09, 2013 at 11:01:49AM -0600, Bob Proulx wrote:
> I am pretty sure that getent is not available on HP-UX for an example
> of a classic legacy Unix system.
I can confirm this up through 11.11:
imadev:~$ uname -a
HP-UX imadev B.10.20 A 9000/785 2008897791 two-user license
imadev:~$ type
On Thu, Apr 11, 2013 at 01:05:43PM +, Lenga, Yair wrote:
> Is it possible to add back the functionality to allow the child process to
> somehow retrieve it's OWN PID.
You are looking for the BASHPID variable, which expands to the process
ID of the current bash process (even in a subshell).
On Thu, Apr 11, 2013 at 04:15:45PM +, Lenga, Yair wrote:
> + The man page list BASH_VERSION, etc., but no indication of BASHPID. It's
> probably a good idea to put a note next to '$!' about BASHPID.
It is certainly in the man page:
BASHPID
Expands to the process ID of the c
On Fri, Apr 12, 2013 at 11:44:49AM +, Lenga, Yair wrote:
> The core question is how to retrieve the status of a command, when running
> with '-e'
http://mywiki.wooledge.org/BashFAQ/105
On Thu, Apr 18, 2013 at 11:59:40AM +0200, and...@coolbox.se wrote:
> The ARITHMETIC EVALUATION section of the man page claims equivalence with C
> for all the operators, but in reality bash does not perform short circuit
> evaluation, which implies that the logical operators do NOT produce the same
On Sun, Apr 21, 2013 at 12:25:20AM -0700, Linda Walsh wrote:
> If I 'reedit my last "statement", it indents 8 spaces/tab.
What does this sentence mean? I am completely stumped. What is
the sequence of steps you are actually performing?
On Mon, Apr 22, 2013 at 10:54:35AM -0700, Linda Walsh wrote:
> Type in this:
> echo 'while read fn;do
> d=${fn%.zip}
This is where I lose you completely. If I press Tab where you indicate,
nothing happens at all.
If I press Tab twice in a row there, bash offers to tab-complete against
all the fi
On Mon, Apr 22, 2013 at 12:35:02PM -0700, Linda Walsh wrote:
> I.e. do whatever you do to insert a TAB there. for me, I press TAB,
> Others have to work around BASH's unwanted, 4.x behavior.
I am not able to reproduce your problem.
Here is what I did:
imadev:~$ echo 'x
y
z'
Which means
On Wed, Apr 24, 2013 at 08:02:29PM -0700, Linda Walsh wrote:
> My terminal is displayed via 'X' --- X pics up
> the actual characters that were echoed to the screen. If TABS are
> used, it put's TABS in the copy/paste-buffer.
That is not how my terminal works.
imadev:~$ echo $'tab>\t
On Sun, May 12, 2013 at 05:50:18PM -0500, Peng Yu wrote:
> set -o vi.
>
> Then I type v to enter the vi editor. In the vi editor, I type 'cd
> /tmp'. Then, I get the following screen output. Notice that the prompt
> does not change immediately after the cd command. Could anybody
> reproduce this b
On Tue, Jun 04, 2013 at 04:39:31PM +0530, kartik...@gmail.com wrote:
> Description:
> A while inside a while loop (nested while) doesnt work and also the vim /gvim
> doesnt highlight the second while loop
For issues with the vim/gvim highlighting, you'd need to report the
problem in vim, not in b
On Thu, Jun 06, 2013 at 03:48:09PM -0700, Linda Walsh wrote:
> I wanted to test to see if a function was defined
imadev:~$ unset foo
imadev:~$ foo=variable
imadev:~$ bar() { echo I am a function; }
imadev:~$ declare -f foo >/dev/null 2>&1 ; echo $?
1
imadev:~$ declare -f bar >/dev/null 2>&1 ; echo
On Fri, Jun 07, 2013 at 09:09:53PM +0800, jida...@jidanni.org wrote:
> Well OK but sometimes a script could be running for years, during which
> any change to a file will result in bash executing random bytes...
This is why you don't edit an installed script in-place. Instead, you
move it aside,
On Fri, Jun 07, 2013 at 10:15:46PM +0800, jida...@jidanni.org wrote:
> Well it is going to happen anyway, so maybe bash should check by
> default, and not check if -o risky is set or something. It can't be that
> expensive.
Yes it can. You're talking about adding a ridiculous amount of extra
chec
On Sun, Jun 09, 2013 at 08:39:10AM +0800, jida...@jidanni.org wrote:
> # gdk-pixbuf-query-loaders >|
> /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
> bash: gdk-pixbuf-query-loaders: command not found
I know it doesn't directly address your issue, but in cases like these,
I find tab
On Sun, Jun 09, 2013 at 02:02:02PM -0700, Linda Walsh wrote:
> I was wondering if I was missing some syntax somewhere...
> but I wanted to be able to pass the name of a hash in
> and store stuff in it and later retrieve it... but it
> looks like it's only possible with an eval or such?
Passing arr
> On 10 Jun 2013 14:15, "Chris F.A. Johnson" wrote:
> >It is not the least bit difficult with eval:
> >
> > eval "array=( \"\${$1[@]}\" )"
On Mon, Jun 10, 2013 at 09:17:23PM +0800, Chris Down wrote:
> Enjoy your arbitrary command execution.
To be fair, Chris Johnson was probably assuming a p
On Mon, Jun 10, 2013 at 10:23:10AM -0400, Chris F.A. Johnson wrote:
> On Mon, 10 Jun 2013, Chris Down wrote:
>
> >Enjoy your arbitrary command execution.
>
>Can you give me an example, using the code I posted, where that would
>happen?
> >On 10 Jun 2013 14:15, "Chris F.A. Johnson" wrot
On Wed, Jun 12, 2013 at 07:37:09AM +0200, Sascha Gaspar wrote:
>The \H in PS1 adds the hostname without the domain to the prompt.
>According to the man page \h outputs the hostname up to the first `.'
>and \H outputs the the hostname. I think that should be the FQDN?
Well, the manual s
On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
> So how can my showsize function be mangling the input in a way that
> prevents proper execution, but isn't recorded by bash?
What makes you believe it's this function that's causing your problem,
and not something else, such as a PROMP
On Thu, Jun 13, 2013 at 04:42:36PM -0700, Linda Walsh wrote:
> Chris F.A. Johnson wrote:
> > The baskspaces (\b) are erasing your input, not the function's
> > output.
That's incorrect. A backspace character sent to a terminal device
moves the cursor (or does whatever else the terminal choose
On Fri, Jun 14, 2013 at 06:25:12AM -0500, Dan Douglas wrote:
> Also forgot to mention (though it should be obvious).
>
> $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo
> jo); f "a[\$(echo yes this even applies to namerefs>&2)0]"'
> yes this even applies to namerefs
N
On Sat, Jun 15, 2013 at 12:36:22PM -0700, Linda Walsh wrote:
> John Kearney wrote:
> >There is also a backdoor approach that I don't really advise.
> >val="${ArrayName}[Index]"
> >echo "${!val}"
> -
> Don't advise? Any particular reason? or stylistic?
I'd shared this advice ("don't use
On Thu, Jun 20, 2013 at 12:39:56AM +0800, Chris Down wrote:
> On 20 June 2013 00:29, DJ Mills wrote:
> > wordsplitting and pathname expansion do not occur within the
> > [[ keyword.
>
> $ > foo
> $ [[ foo == * ]] && echo bar
> bar
That's pattern matching, which is neither word splitting nor path
On Wed, Jun 19, 2013 at 06:12:57PM -0500, Dan Douglas wrote:
> Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
> not so sure it's actually better in practice. (talking about standard shell
> pattern matching of course)
I'm fairly sure nobody on the entire planet uses t
On Fri, Jun 21, 2013 at 02:39:14AM -0500, Dan Douglas wrote:
> > If you're writing a script in bash, you MUST NOT use the [a-z]
> > or [A-Z] ranges, or any other alphabetic ranges, unless you are
> > working in the POSIX locale. If you use an alphabetic range in any
> > other locale, you invite di
On Tue, Jul 02, 2013 at 05:36:43AM +0200, Tomasz Tomasik wrote:
> bash -c 'foo="??ó??w"; echo ${foo^^}'
> ??ó??W
>
> Characters with diacritical marks are not affected.
I get the same result in ISO-8859-1:
imadev:~$ x='fóo'; echo "${x^^}"
FóO
imadev:~$ locale
LANG=en_US.iso88591
LC_CTYPE="en_US.
On Fri, Jul 05, 2013 at 12:50:53AM +0800, Chris Down wrote:
> > PS1='\h Hello everybody\n\e[1;35m\]Hi\e[0m\]>'
> You need to properly indicate that the control codes are zero-width
> (by using \[ and \]). Without them, this is expected behaviour.
>
> Better, don't hardcode the escape code
On Fri, Jul 05, 2013 at 12:21:13PM +, BASTIDON, Stéphane wrote:
> Now my case is a little more complex:
> I want my prompt changes colors according to $PWD Then I write something like
> that:
This is the kind of thing where I suggest using PROMPT_COMMAND.
normal=$(tput sgr0) red=$(tput setaf
On Wed, Jul 10, 2013 at 02:54:17PM -0700, Jason Sipula wrote:
> ~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb
This isn't a bash issue. Mysql is prompting for a password, either
on standard input or by directly opening /dev/tty. In either case,
the issue is with mysql.
On Thu, Jul 11, 2013 at 10:47:12AM -0700, Jason Sipula wrote:
> I still think this is a bash issue. After the command terminates, you must
> restart your bash session to return to normal functionality. Nothing typed
> into the terminal displays but it does receive it.
If the terminal has been mess
On Thu, Jul 11, 2013 at 10:53:11AM -0700, Jason Sipula wrote:
> The second issue is once the command terminates, bash session does not
> behave normally at all. Nothing typed into the terminal over SSH or
> directly on the console displays, however it does receive the keys. Also,
> if you repeatedl
On Sun, Jul 14, 2013 at 02:06:07PM -0700, Linda Walsh wrote:
> I was trying to find the location of the current development
> source.
>
> I followed the access instructions at:
> https://savannah.gnu.org/cvs/?group=bash
http://savannah.gnu.org/git/?group=bash
On Wed, Jul 17, 2013 at 02:53:41PM +, Mark W. Johnson wrote:
> function _cd { command cd "$@"; }
> alias cd=_cd
>
> In my real _cd function it saves off the directories visited, but I didn't
> want to complicate the issue, so I replaced my useful _cd function to
> something useless
On Wed, Jul 17, 2013 at 08:42:17PM +, gscant...@comcast.net wrote:
> I wish to ssh this command to several hosts:
> ls -alst "dir_with_spaces"
for host in "${hosts[@]}"; do
ssh "$host" bash <<-'EOF'
ls -alst "your directory"
EOF
done
The - in front of the here document's d
On Sat, Jul 27, 2013 at 01:34:53AM +0900, David H. wrote:
> # The test string:
> $ echo $instring
> root:x:0:0:root:/root:/bin/bash
>
> # Gives incorrect (unexpected) output:
> $ ( IFS=: read -a strings < <( echo $instring ) ; printf '[%s]\n'
> "${strings[@]}" )
> [root x 0
On Fri, Jul 26, 2013 at 10:38:46PM +0200, Andreas Schwab wrote:
> Greg Wooledge writes:
>
> > Your unquoted $instring is being split into fields by bash, which is
> > operating with IFS=: at that point.
>
> Variable assignments are supposed to be performed _after_ redir
On Mon, Jul 29, 2013 at 06:36:58PM +0300, Pierre Gaston wrote:
> it's not clear (like it is for, say, exit) what the relationship
> between return and process is.
> I guess most people expect it to not care about subshells and just
> execute the statement after the function call.
"Most people" bar
On Tue, Jul 30, 2013 at 01:15:59PM +0300, Pierre Gaston wrote:
> >> while :;do ( while :;do break 2; done);echo foo;done
> >>
> >> Should this raise an error? is the break in a loop context? what's a
> >> loop context?
The break occurs in a subshell, which means it cannot communicate what
I presum
On Tue, Jul 30, 2013 at 04:12:07PM +0200, Roman Rakus wrote:
> >>f1() {
> >> : | while :; do return 3; done
> >> echo $?
> >> return 1
> >>}
> >>echo $?
> >>f1; echo $?
> >>return 2
> My point is that the `return 3' in while loop is in subshell and will
> not return from the function
On Wed, Jul 31, 2013 at 02:09:23AM +0200, Jörn Hees wrote:
> i think this would be a very useful feature and i don't seem to be alone:
> http://stackoverflow.com/questions/5955577/bash-automatically-capture-output-of-last-executed-command-into-a-variable
Bash has no knowledge of, and no way to int
On Thu, Aug 01, 2013 at 09:37:38AM +0200, Lakshminarasimhan Srinivasan wrote:
> ldapscripts do not work from inside a "while read line" loop.
> The exact same scripts were working fine until the last upgrade
> -
> #!/bin/bash
> echo "Testing
On Fri, Aug 09, 2013 at 10:47:21PM -0600, Bob Proulx wrote:
> John Vincent wrote:
> > echo {1..2000}
> > it runs, but afterwards whenever I enter another command I get the error:
> > -bash: fork: Cannot allocate memory
>
> You need to allocate more virtual memory space to your machine. You
>
On Mon, Aug 19, 2013 at 05:50:31AM +0200, Chris Down wrote:
> On 2013-08-18 16:57, David Lehmann wrote:
> > The ((i++)) fails only when the result is 1. When the result is 0 or 2, it
> > does not fail. This is a problem when 'set -e'.
>
> This is normal and expected. If the value returned in an
On Mon, Aug 19, 2013 at 05:53:03AM +0200, Chris Down wrote:
> On 2013-08-18 17:46, Linda Walsh wrote:
> > I don't find the variable for the process ID of the
> > last started background process documented in the bash manpage...
> >
> > Am I just missing it, or did it get left out by accident or
> >
On Mon, Aug 19, 2013 at 08:02:39PM -0700, Linda Walsh wrote:
> Yes, I see what you mean. I guess I'm not real certain
> as to why, if "CDPATH=~/Documents", and I type "cd Pictures/family"
> and end up in ~/Documents/Pictures/family, then PATH shouldn't work
> the same way.
There are several
On Tue, Aug 20, 2013 at 05:48:12PM +0300, Aharon Robbins wrote:
> In article you write:
> >1) PATH is used by the kernel (exec family) to determine how commands are
> > executed. The way PATH is used by the kernel is not likely to change.
> > Having the shell treat it differently would lead t
On Wed, Aug 21, 2013 at 02:22:24AM -0800, Ken Irving wrote:
> $ cat $(ambler.method dispatch)
> #!/bin/bash
> method=$1 && shift
> test -n "$method" || exit
> for s in $(ls|shuf); do
> tob $s.$method "$@" &
> done
As far as I can tell, this is some incredibly stupid
On Thu, Aug 29, 2013 at 12:57:22PM -0400, DJ Mills wrote:
> On Thu, Aug 29, 2013 at 12:42 PM, DJ Mills wrote:
>
> > When using a non-default IFS (a default IFS would trim them), a single
> > empty trailing field is ignored for read -a.
> >
> > IFS=: read -rd '' -a arr < <(printf %s ':foo:bar:');
On Wed, Sep 04, 2013 at 10:06:16PM -0700, kneuf...@gmail.com wrote:
> $ [ ! -e stuff.txt ]; echo $?
> 1
> $ [ ! -a stuff.txt ]; echo $?
> 0 # what?
>
> Both these version show the exact same behaviour.
>
> Fedora 18, bash 4.2.45(1)-release
> OSX, 3.2.48(1)-release
Also occurs in 4.3.0-beta.
On Sun, Sep 08, 2013 at 11:21:56AM -0500, Dennis Williamson wrote:
> The man page says "Note that a negative offset must be separated from the
> colon by at least one space..."
Enclosing the negative offset in parentheses also works.
The reason you must use either parentheses or spaces between th
On Wed, Sep 18, 2013 at 11:54:13PM +0800, zxycscj wrote:
> I have downlaod bash-4.2.tar.gz and all the patches for it.
> how to use the patch files to install?
>
> http://ftp.gnu.org/gnu/bash/
> bash-4.2.tar.gz
>
> http://ftp.gnu.org/gnu/bash/bash-4.2-patches/
> bash42-001.sig
> bash42-001.txt
..
On Thu, Sep 26, 2013 at 06:27:10AM +, Hinrik Örn Sigurðsson wrote:
> The "&&" operator in bash seems to inhibit backgrounding when run over
> ssh. You can try it with the following:
>
> ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &"
>
> The above command will wait for sleep(1)
On Fri, Sep 27, 2013 at 03:50:09PM +0530, Roland Winkler wrote:
> I guess there is not too much one can say about the bash built-ins
> `true' and `false'. Nonetheless, I suggest that the info pages
> should list these built-ins individually like other built-ins.
> Currently, the only hint on their
On Thu, Oct 03, 2013 at 03:18:16AM -0700, vic...@vsespb.ru wrote:
> -e will return file not exists, even if it does, when permission denied error
> happen. I am wondering if this documented/correct behaviour or no.
I assume you mean that bash will return 1 (failure) for [[ -e /path/to/file ]]
when
On Sun, Oct 06, 2013 at 09:37:00PM -0300, Carlos Pita wrote:
> I'm not completely sure whether this is a bug or not but it seems
> not possible to immediately exit a shell when an error happens at 2+
> levels of subshell nesting.
Exiting in a subshell will never cause the parent shell to exit,
r
On Mon, Oct 07, 2013 at 11:01:11AM +0200, Bart?omiej Palmowski wrote:
> $ ( set -e; echo foo; false; echo bar; ) # this one is expected
> foo
> $ ( set -e; echo foo; false; echo bar; ) || true # this one is not expected
> foo
> bar
set -e is useless rubbish that should be avoided.
See http://mywik
On Mon, Oct 07, 2013 at 11:58:48AM -0300, Carlos Pita wrote:
> > Exiting in a subshell will never cause the parent shell to exit,
> > regardless of depth.
>
> This is not true in general.
> set -e; (exit 1); echo "I don't exist"
In this case, it is the "set -e" which may or may not cause the pare
On Wed, Oct 16, 2013 at 08:53:27PM +0800, jida...@jidanni.org wrote:
> We use ^P^P^P^P^P^P^P... to finally get to the top of the mess.
... why would you do that? Also, how is this a bug?
> Then we must use ^K^N^K^N^K^N^K^N^K^N^K^N... to clean it up.
>
> However this leaves many blank lines in h
On Wed, Oct 23, 2013 at 01:17:12PM -0700, Evan Gates wrote:
> declare -A aarr
> aarr[\]]=rbrac
> declare -p aarr # this should print a legal declaration for aarr
> eval $(declare -p aarr) # results in "bash: []]=rbrac: bad array subscript"
Cannot reproduce in bash 4.3-beta2.
imadev:~$ unset a
ima
On Wed, Oct 30, 2013 at 08:01:02AM +, Peggy Russell wrote:
> A variation:
>
> shopt -s nullglob
> for f in ${1:-.}/*; do
> if [[ "${f}" != *-IGN-* ]];
> then printf -- '%s\n' "${f}"
> fi
> done
You missed one set of quotes:
for f in "${1:-.}"/*; do
On Wed, Oct 30, 2013 at 12:58:54PM +0100, Andreas Schwab wrote:
> Greg Wooledge writes:
>
> > On Wed, Oct 30, 2013 at 08:01:02AM +, Peggy Russell wrote:
> >> A variation:
> >>
> >> shopt -s nullglob
> >> for f in ${1:-.}/*; do
> >>
On Thu, Nov 14, 2013 at 06:50:33AM +0100, Piotr Grzybowski wrote:
> My main point is: this patch means that every user that has access to
> who-knows-how restricted shell can open listen sockets, and unless
> someone thought of using grsecurity to deny access to bind(2) it is
> unrestricted.
Rest
On Fri, Nov 22, 2013 at 10:00:28AM +0400, Aleksey Midenkov wrote:
> 1: shopt -s unsplit_vars
>
> which will turn off word splitting for var expansion.
Basically, you want zsh.
On Sun, Nov 24, 2013 at 08:41:46PM -0700, Bob Proulx wrote:
> Aleksey Midenkov wrote:
> > rmcmd="$rmprog -f"
> >
> > Because it will fail for files with spaces.
>
> I am sure we disagree but I don't consider making rm program names
> have spaces to be reasonable. :-/
>
> What would it be? "rem
On Tue, Nov 26, 2013 at 03:38:17AM -0500, Chris F.A. Johnson wrote:
> On Mon, 25 Nov 2013, Edward Peschko wrote:
> >Is there a way to have the prompt - or any other environmental
> >variable - change in this way, based off external command?
>
> Use single quotes:
>
> PS1='`whoami`@`hostname`'
On Thu, Dec 12, 2013 at 07:53:32AM +0100, Piotr Grzybowski wrote:
> Yuri: I have verified that under linux 3.2.0, bash-4.2.25, nothing of
> the sort takes place. tee gets /dev/fd/${somefd}, why it is not
> supported in bsd kernel i have no idea, but I thought it was.
On OpenBSD, at least, this is
On Tue, Dec 10, 2013 at 11:28:31PM -0800, toddbst...@gmail.com wrote:
> Machine Type: x86_64-redhat-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 45
> Just run 'read -t1' and note that the behavior seems not different from
> simply running 'read' without arguments.
I can't duplicate
On Tue, Dec 17, 2013 at 03:18:31PM +0200, Sergey Skripnick wrote:
> Description:
> When executed script (by `source' or by dot syntax) which have 0d0a
> characters as a newlines, readed variables have incorrect values. As you
> can see below, 0d character is included,
This is expected.
>
On Mon, Dec 23, 2013 at 11:57:32PM +0100, rens wrote:
> ls -1 /usr/bin|head -10 |while read fname
> do
> cval=$(( cval +1 ))
> echo cval = $cval file = $fname
> done
> # one would think cval is now 10. but it is not, contrary to any other
> programming language
>
> echo " after while: c
On Tue, Dec 24, 2013 at 07:49:28PM +0100, rens wrote:
> I understand the technical origin of the behaviour.
> Spend +25 yrs in unix. I am so old, that I remember fighting (at my
> 40th) with linux 0.79, I think
>
> However, I am questioning if this is what a programming language should do.
On Wed, Dec 25, 2013 at 03:11:13PM -0800, Eduardo A. Bustamante López wrote:
> On Wed, Dec 25, 2013 at 06:41:17PM +0400, vollitwr . wrote:
> > The patterns [A-C] and [ABC] work different! [A-C] ignores case and
> > [ABC] does not.
It's not actually ignoring case. It's just that in some locales,
On Fri, Dec 27, 2013 at 07:14:39AM +0400, vollitwr . wrote:
> It is obvious that letters 'b'
> and 'B' are different for everybody in any locale
No, they're the same letter. One's upper-case and one's lower-case.
> How is it possible to use sequence like aAbBcC... for the
> range patterns?!
Whe
On Tue, Jan 07, 2014 at 12:45:42AM +0200, DanielB wrote:
> declare -a array=( 'sf052' 'to060' 'pw' 'qb099' 'pw22' 'wp039' 'wx12'
> 'wx11' )for subD in "${array[@]}"; do
> echo $subDdone
>
> output:
>
> sf052
> to060
> pw
> qb099 pw22
> wp039 wx12
> wx11
I can only guess that your terminal is
On Tue, Jan 07, 2014 at 10:36:54PM -0700, Bob Proulx wrote:
> lina wrote:
> > How can I print the 0.05, 0.10 ... 1.0 out, with the step of 0.05
Floating point does weird things. A first approach might look like
this:
awk 'BEGIN {for (i=0.05; i<=1.0; i+=0.05) printf ("%.2f\n", i)}'
But when I
On Thu, Jan 09, 2014 at 01:56:11PM +0800, lina wrote:
> Hi Bob, my fault, I didn't realize this was a wrong way to start a new
> conversation, by renaming the Subject and deleted everything inside. How
> could they figure out it is from that thread?
Email headers include a field called "In-Reply-T
On Thu, Jan 16, 2014 at 03:46:38PM -0800, Eduardo A. Bustamante López wrote:
> [[ $'\a' =~ $'\a' ]] -> 0
> [[ $'\a' =~ $'\\\a' ]] -> 0
> [[ $'\a' =~ $'\\[\a]' ]] -> 1
> ---
> [[ $'\177' =~ $'\177' ]] -> 0
> [[ $'\177' =~ $'\\\177' ]] -> 1
> [[ $'\177' =~ $'\\[\177]' ]] -> 1
> Notice that only $'\1
On Fri, Jan 17, 2014 at 08:53:07AM -0500, Chet Ramey wrote:
> On 1/17/14 8:01 AM, Greg Wooledge wrote:
> > I would expect [[ x =~ yx ]] to fail (return 1) every time.
>
> There is a question about the correct behavior when y == '\', since the
> backslash is specia
On Sat, Feb 01, 2014 at 05:36:17PM +0100, Mathieu Malaterre wrote:
> #!/bin/bash
>
> for i in {0..4294967295}; do
> echo $i
> done
Others said not to do that. They are correct, but they didn't tell you
what to do instead.
for ((i=0; i<=4294967295; i++)); do
echo $i
done
The brace expansion
On Thu, Feb 06, 2014 at 11:51:25AM +0800, Dan Jacobson wrote:
> # su - nobody
> No directory, logging in with HOME=/
> $ cat /tmp/r
> LC_CTYPE=zh_TW.UTF-8 N=$(echo ??|iconv -t big5 -f utf-8) sh -xc ': $N'
> $ sh /tmp/r
> /tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(ech
On Wed, Mar 19, 2014 at 02:18:52PM +0400, Dmitry Arkhireev wrote:
> And if run it sample with echo $I after ((I++)) everything works as expected
> I=0; while [ $I -ne 1 ]; do ((I++)); echo $I; done; echo $?
> 1
> 0
Here, $? is the exit status of the echo, instead of the ((...)) command.
The ((...)
On Tue, Mar 25, 2014 at 08:24:13PM +0900, Kusanagi Kouichi wrote:
> Description:
> Bash's builtin printf cannot write more than one line to
> /proc/pid/uid_map because printf writes one line at a time
> and uid_map can be written only once.
Sounds like Bash is using the standard
On Wed, Mar 26, 2014 at 12:54:12PM +, Pádraig Brady wrote:
> On 03/25/2014 02:12 PM, xeon Mailinglist wrote:
> > For each file inside the directory $output, I do a cat to the file and
> > generate a sha256 hash. This script takes 9 minutes to read 105 files, with
> > the total data of 556MB and
On Wed, Mar 26, 2014 at 09:02:02PM -0700, billyco...@gmail.com wrote:
> The original intention was to play a randomly sorted list of songs (except
> ABBA):
See http://mywiki.wooledge.org/BashFAQ/026
I would use an approach like this:
files=()
while IFS= read -r -d '' file; do
files+=("$file")
On Thu, Mar 27, 2014 at 08:19:39AM -0700, esoj wrote:
> I need to specify a variable path after #! but seems to me that bash can't
> do this.
> For example I need to specify the $HOME or ~ path as in:
>
>
> #!~/bin/python
> or
> #!$HOME/bin/python
This belongs on help-bash, not bug-bash. That s
On Thu, Mar 27, 2014 at 07:31:31PM -0700, Linda Walsh wrote:
> So whether or not to use /def/fd is a build time option?
On many commerical Unix systems (which don't have /dev/fd/), Bash
falls back to using named pipes.
> It's a minority of scripts but have noticed the message
> in som
701 - 800 of 1972 matches
Mail list logo
