Re: ReadLines and Substraction

[pk]

yetcom wrote:

 Hello Everyone,
 
 I have an issue regarding the bash. I have 2 different files and each
 of them involves some float point numbers for each lines. I want to
 subtract each line then put all the results into a file. The first
 line float number will be subtract with the first line of other file
 and the second with the other second... and etc...
 
 When I read both files with:
 
 cat ./Temp1.log | while read line; do
 
 cat ./Temp2.log | while read line; do
 
 #It reads the first line of temp1, I also need to read the
 first line of temp2. However, Temp2 will be read until the end of file
 so that I cannot read one by one for each lines of different files.
 
 done
 
 done
 
 
 If you can help me with this, will be very happy for that. Thanks in
 advance.

try

paste -d '-' file1 file2 | bc  results

Re: Mapfile callback access to current line

[pk]

DennisW wrote:

 Mapfile would be that much more powerful if the callback function had
 access to the current line. Is there any chance this might be added in
 the future?

Can't answer directly on this, but it looks like the gateway between this 
group and the mailing list hasn't worked for a long time. Is this intended? 
Was it announced somewhere?

Re: Variable getopts lost

[pk]

Daniel Bunzendahl wrote:

 My question wasn't fokused on my wrong script. I think there is something
 wrong or limited by the System...
 Maybe you can give me a tip I should search for...

You've got it already...either invoke the script with its name (not through 
bash), or use bash -- etc.

Re: FWD: About Bash Script

[pk]

Curtis wrote:

 Here's what I have but i'm getting some errors
 
 #!/bin/bash
 
 
 if ! (-e b.txt);

ITYM

if [ ! -e b.txt ]; then
...

Re: FWD: About Bash Script

[pk]

Curtis wrote:

 if [! -e b.txt];

Please note that should literally be

if [ ! -e b.txt ];

NOT

if [! -e b.txt];

Try running the latter and you'll get errors.

Re: Is there a special variable for the directory where the script is in?

[pk]

Peng Yu wrote:

 $0 gives the file name of the script. I could use several shell
 command to get the directory where the script is in. But I'm wondering
 if there is an easy-to-use variable that refers to the directory where
 the script is in?

See this page:

http://mywiki.wooledge.org/BashFAQ/028

Re: best way to test for empty dir?

[pk]

Marc Herbert wrote:

 For purists, does this one works even better?
 
 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...

Re: best way to test for empty dir?

[pk]

Chris F.A. Johnson wrote:

 On Thu, 10 Dec 2009, Marc Herbert wrote:
 
 Does anyone know a more elegant way to check for file existence?
 Something that does not fork a subshell. And is also more readable
 maybe. And is obviously not much longer.
 
 empty_dir()
 { 
 test x$(echo $1/*$2) = x$1'/*'$2
 }
 
 
 Warning: I find neither noglob nor ls elegant, sorry!
 
 is_file()
 { 
 for f
 do
 [ -f $f ]  return
 done
 return 1
 }
 
 is_file /path/to/dir/* || echo empty

This fails if the directory contains a file called *. 

Re: Fullscreen unchecking show menubar.

[pk]

Rodney Varney III wrote:

 Repeat-By:
 View, fullscreen, view, uncheck show menubar

Where are you seeing any menubar in bash?
You're probably referring to the terminal in which bash is running. In that 
case, it's likely that it's a problem with the specific terminal 
implementation (eg gnome terminal, konsole or others).

Re: bash is not capable of comparing of strings and real numbers

[pk]

phani krishna jampala wrote:

 bash is not capable of comparing of strings ( imean interms of lessthan or
 greater than etc) 

It is, if you use [[  ]]

a=abcd
b=bcde
if [[ $b  $a ]]; then
  echo $b is greater than $a
fi

 and real numbers ( the float values). 

True, but I can't really speak as to whether this is planned or not (I think 
it isn't, but of course I might be wrong).

Re: output redirection with process substitution asynchronous?

[pk]

pjodrr wrote:

 in my original example the seq 4 runs in the current shell
 while here the command runs in a subshell.

It would be nice if you explained what it is you're attempting to do, rather 
than ask for a solution for what you're thinking would do that.

Re: output redirection with process substitution asynchronous?

[pk]

pjodrr wrote:

 Hello,
 
 how can I prefix every line of output of some command with a
 timestamp?  I thought like this:
 
 $ exec 3 (while read line; do echo $(date): $line; done)
 $ seq 4 3
 Friday, December  4, 2009  4:20:29 PM MET: 1
 $ Friday, December  4, 2009  4:20:29 PM MET: 2
 Friday, December  4, 2009  4:20:29 PM MET: 3
 Friday, December  4, 2009  4:20:29 PM MET: 4
 
 please note that the prompt ($) returns before the command completes.
 Why is the
 process substitution asynchronous?
 Does anybody know of a better way to accomplish this?

What's wrong with

seq 4 | while read line; do echo $(date): $line; done

Re: functions can be created with dotted name but not removed

[pk]

Michael O'Donnell wrote:

 A bash function with a dot in its name can be created and used with no
 problems but cannot be removed - the unset command chokes on the name.
 
 
 Repeat-By:
 
 This sequence yields the expected results:
 
 function f() { echo $FUNCNAME ; }
 f
 unset f
 
 ...while this sequence fails during the unset phase with the complaint
 that the name is not a valid identifier:
 
 function f.dot() { echo $FUNCNAME ; }
 f.dot
 unset f.dot

Try 

unset -f f.dot

Re: Doubt on variable $

[pk]

visco wrote:

 Could anyone tell me what is the purpose of $
 
 I found it in a Makefile as follows
  $(CXX) $(CXXFLAGS) -c $ -o $@

That's not a bash variable. It's a Makefile variable.

http://www.gnu.org/software/make/manual/make.html#Automatic-Variables

 Also it would be nice if anyone could give a link explaining spl.
 variables used in bash

There's a Special Parameters section in the bash man page.

Re: IFS handling and read

[pk]

Marc Herbert wrote:

 Chris F.A. Johnson a écrit :
Why should it be the last element of a pipeline that is executed in
the current shell and not the first?
 
 
 Because that's POSIX' choice?

No, POSIX allow either behavior. In fact, it allows any behavior ranging 
from running all parts in their own subshells, to running all parts in the 
current shell.

Re: IFS handling and read

[pk]

pk wrote:

 Because that's POSIX' choice?
 
 No, POSIX allow either behavior. In fact, it allows any behavior ranging 
 from running all parts in their own subshells, to running all parts in the 
 current shell.

...each command of a multi-command pipeline is in a subshell environment; 
as an extension, however, any or all commands in a pipeline may be executed 
in the current environment. All other commands shall be executed in the 
current shell environment.

Re: Use of pipe in $( filename | program) returns null

[pk]

Chet Ramey wrote:

 r...@saturn.syslang.net wrote:
 
 Description:
 use of $( filename | program) does not work. It either should or it
 should be properly documented. The problem also happens on bash4.
 
 Repeat-By:
 
 qq=$( /etc/passwd | grep sys)
 echo $qq
 # result is null
 
 Fix:
 Either fix the docs to tell people that a pipe is not allowed or fix the
 code to allow it.
 
 That construct is very limited.  As the bash man page says:
 
 The command substitution $(cat file) can be replaced by the equivalent
 but faster $( file).
 
 That seems pretty clear.

Yeah, and then based on that he probably thought that

$(cat file | grep sys)

could be replaced by

$( file | grep sys)

which is not the case.

Re: printf %q and $'...'

[pk]

Antonio Macchi wrote:

 $ printf \x00\n | cat -A
 ^@
 
 it works, so why...
 
 $ printf $'\x00' | cat -A
 $

Read carefully ALL the answers you've been given. The short version is that 
$'\x00' is interpreted by bash itself, while '\x00\n' is interpreted by 
printf only. But DO READ the answers you've got, because your question 
denotes you haven't done that.

Re: printf %q and $'...'

[pk]

Antonio Macchi wrote:

 but...
 
 $ printf one$'\x00'two\\n
 
 +-+-+-+-+-+-+--+
 |p|r|i|n|t|f|\0|
 +-+-+-+-+-+-+--+
 
 +-+-+-+--+-+-+-+--+--+
 |o|n|e|\0|t|w|o|\n|\0|
 +-+-+-+--+-+-+-+--+--+
 
 so the output should be one, and stop here!
 
 but the real output is
 onetwo
 
 so, imho, there's something more...
 
 
 
 
 imadev:~$ echo $'foo\0bar'
 foo
 
 
 sorry... I'm a little bit confusing... look
 
 $ echo foo$'\0'bar
 foobar

You still fail to read the other answers. Hint: read them (and I do mean 
it), then find out how each command expands its arguments, what is seen by 
bash, and what is seen by the commands.

Re: for i in {1..100000...

[pk]

Antonio Macchi wrote:

 what's the rasonable limit in using this compact contruct, after which 
   the for (( i=0; i1000...; i++ )) became better?

You didn't even bother trying eh?

$ for i in {0..10}; do echo $i/dev/null; done
bash: xmalloc: ../../../bash/lib/sh/stringvec.c:40: cannot allocate 
800016 bytes (0 bytes allocated)

$ for ((i=0;i=10;i++)); do echo $i/dev/null; done

Re: qwerty

[pk]

Antonio Macchi wrote:

 I'm on error, I know... but, in your bash-ref guide you don't explain a 
 lot printf
 
 and in man printf don't do it too...
 
 from man printf
 -
 NOTE: your shell may have its own version of printf, which usually 
 supersedes the version described here. Please refer to your shell’s 
 documentation for details about the options it supports.
 -

Neither man printf nor the printf utility you might have installed in your 
system is provided by bash.

On Ubuntu, for example

$ dpkg -S /usr/bin/printf
coreutils: /usr/bin/printf

The man page mentions that the full documentation is available by doing 
info coreutils 'printf invocation', and that page does seem indeed more 
comprehensive than the man page. But then again, neither is bash territory.

Re: triggering of ERR trap differs between bash 3.2.39 4.0.28

[pk]

Amit Dor-Shifer wrote:

 I've the following script:
 
 set -eE
 on_error() { echo ERROR ERROR; }
 trap on_error ERR
 
 if [ -n $(echo $1 |grep a) ];then
echo input contains 'a'
 fi
 
 When executed under bash-4, on_error is evaluated as part of the
 expression in the 'if'. This does not happen in 3.2:

I think this is part of the new behavior of -e in bash 4. See for example 
here:

http://www.mail-archive.com/bug-bash@gnu.org/msg06288.html

Re: doing simple math in bash :: prb with leading zero

[pk]

ken wrote:

 This is what I get on Linux running on an i686.
 
 Bash should be smart enough to know that 09 = 9
 -- and it does sometimes, but not all the time.
 Surprise!!

From the bash manual:

Constants with a leading 0 are interpreted as octal numbers.  A leading 0x
or 0X denotes hexadecimal.

Re: how to keep newlines in ``

[pk]

Sam Steingold wrote:

 this:
 foo=`ls`
 echo $foo
 will print files in one line even though ls prints them with newlines.
 is there a way to preserve newlines in the above echo?
 thanks.

echo $foo

Re: time seg fault

[pk]

rjustinwilli...@gmail.com wrote:

 Hi all
 
 I have, on a 64-bit system an issue with time hanging. I've installed
 multiple versions, one at a time, and gotten the same results on each
 version.
 
 If I use tcsh, instead of bash, time works.
 
 With bash 3.17, I got a seg fault; with the other versions up through
 4.10, it just hangs and I have to go back in and kill it.
 
 Any thoughts on where this might be breaking? Are there any files bash's
 time tries to use that I should check out?

It's very difficult to tell without at least an idea of what you're trying
to do. Paste a snippet of the code or commands you are using.

Re: RFE: zero prefixed expansion, e.g. {01..02} - 01 02

[pk]

On Friday 5 June 2009 20:28, Till Maas wrote:

 Aloas,
 
 I often need the results of expansion like {01..10} to be prefixed with
 zeros, currently I always need to have two expansions, e.g.
 
 cat foo0{1..9}.bar foo{10..23}.bar
 
 It would be nice if I could use e.g.
 
 cat foo{01..23}.bar
 
 instead to get the same results.

Bash 4 does what you want.

Re: Regex matching oddity (bug, or 'unexpected feature' or...?)

[pk]

On Thursday 28 May 2009 21:58, Linda Walsh wrote:

 But when I used regex pattern matching in the if, the spaces around the
 operator
 caused a failure in matching.  I.e.:
 if [[ $Var=~+([:digit:]) ]] ; then ...
 worked.

worked in the sense that [[ .. ]] evaluated a single argument: the
string $Var=~+([:digit:]). Not different from doing, for instance, 

if [[ foobar ]]; then ...

 
 But:
 if [[ $Var =~ +([:digit:]) ]] ; then ...
 evaluates to 'FALSE', trace(-x) shows the eval as:
 + [[ 4 =~ \+\(\[:digit:]\) ]]

Yes, if the second argument is quoted, it's treated as a literal string. If
you want the regex behavior, you should not quote it:

if [[ $Var =~ +([:digit:]) ]]; then .

That behavior changed at some point during 3.2 (too lazy to check now).

 and inserting a space on only-one side of the operator yielded the error
 message:
 conditional binary operator expected
 at the line of the expression.

Expected: having the space only on side is just like evaluating

if [[ foo bar ]]; then ...

in your case the two strings are

$Var=~  and   +([:digit:])

or

$Varand   =~+([:digit:])

depending on where you put the space.

 Obviously, I can workaround my mis-comprehension and just proceed,
 but I wanted to ask why, what I thought was normal syntax,
 (i.e. args separated by spaces), didn't work.

It did work as documented, although I agree that the change in behavior in
regex match I mentioned before took many by surprise, since your same
question has been asked several time in the past.

Re: Regex matching oddity (bug, or 'unexpected feature' or...?)

[pk]

On Thursday 28 May 2009 22:38, pk wrote:

 Yes, if the second argument is quoted, it's treated as a literal string.
 If you want the regex behavior, you should not quote it:
 
 if [[ $Var =~ +([:digit:]) ]]; then .
 
 That behavior changed at some point during 3.2 (too lazy to check now).

Actually, that happened in 3.2-alpha:

f.  Quoting the string argument to the [[ command's  =~ operator now forces
string matching, as with the other pattern-matching operators.

Re: Is there any mutex/semaphore mechanism in shell scripts?

[pk]

On Wednesday 20 May 2009 21:34, jjjaime wrote:

 
 I would like to execute some functions in parallel, but the last method
 has to wait until the first 2 functions have finished.
 
 The script is:
 
 FUNCTION_1() {
 ...
 }
 FUNCTION_2() {
 ...
 }
 FUNCTION_3() {
 ...
 }
 FUNCTION_1 
 FUNCTION_2
 FUNCTION_3
 
 So, to speed up the execution of the script, I want FUNCTION_1 and
 FUNCTION_2 in parallel. But the script fails when FUNCTION_2 ends before
 FUNCTION_1.
 
 Is there any mechanism for synchronization (i.e. semaphores/mutes) or any
 other suggestion for simulating it?

Please see

http://cfaj.freeshell.org/shell/cus-faq.html#8

Re: big 'list' consumes all memory

[pk]

On Thursday 16 April 2009 11:11, Mart Frauenlob wrote:

 for i in $(seq 0 15755500); do echo $i; done
 -bash: xrealloc: ../bash/subst.c:512: cannot reallocate 182209024 bytes
 (0 bytes allocated)
 
 
 ok, thesis looks confirmed...
 I'm no C programmer, but I try to think logically about it.
 There may be no way around it, as it may be necessary to build the
 complete list, before it's possible to work with it.

If you do it that way maybe yes (or maybe not - I can't really speak), but
of course you can always do

seq 1 15755500 | while read i; etc.

Re: Question

[pk]

On Friday 3 April 2009 03:33, Brandon F wrote:

 When I do traceroute in bash I am always getting
 12-215-11-193.client.mchsi.com as the third or fourth site. I want to know
 how to clear this from my route list. So it will bounce off of a differant
 site. Thank you.

traceroute | sed '/12-215-11-193\.client\.mchsi\.com/d'

(won't bounce off a different site, though :)

Re: order of redirections

[pk]

On Monday 2 March 2009 23:34, lehe wrote:

 
 Hi,
 I have some questions about the paragraph in Bash Reference on
 redirections: Note that the order of redirections is significant. For
 example, the command
   ls  dirlist 21
 directs both standard output (file descriptor 1) and standard error (file
 descriptor 2) to the
 file dirlist, while the command
   ls 21  dirlist
 directs only the standard output to file dirlist, because the standard
 error was duplicated
 as standard output before the standard output was redirected to dirlist.
 
 In the first example ls  dirlist 21, does it mean first ls 
 dirlist and then 21? If yes, then dirlist will not have the content
 of standard error 2.
 
 In the second example ls 21 dirlist, does it mean ls 21 and then
 dirlist where 1 is omit as default before ?

http://bash-hackers.org/wiki/doku.php?id=howto:redirection_tutorial

Re: {# - strange behavior

[pk]

On Monday 23 February 2009 07:31, Antonio Macchi wrote:

 
 Yes, it's ok.  Posix says that printf field widths are specified in
 number of bytes.
 
 
 I've never red nothing about POSIX, 

You should, especially if posting here something like that.

 but imho, in the past, char and 
 byte was synonymous
 
 maybe last POSIX definitions are very old...

No, there has been a new release just some months ago.

Re: is it a bug? (little script)

[pk]

On Sunday 5 October 2008 17:17, Antonio Macchi wrote:

 #!/bin/bash -e
 
 trap rm test_fifo 0
 mkfifo test_fifo
 
 ls /  test_fifo 
 
 exec 90
 
 while read dirname
 do
echo $dirname
 
# if I wait, exits!!!
read -t 2 -p press enter... 09
 done  test_fifo
 
 exec 9-
 
 exit 0

You know what -e does, don't you? 
An expired timeout for read returns failure (as clearly stated in the
manual), so what you see is just the expected behavior.

(and, btw, fiddling with the descriptors is totally useless and confusing
here, since it is not related to the problem).

Re: inconsistent treatment of backslash-bang

[pk]

On Tuesday 22 July 2008 13:38, Lawrence D'Oliveiro wrote:

 And even with the specialness of bang turned off, it still doesn't work
 right:
 
 [EMAIL PROTECTED]:~ set +H
 [EMAIL PROTECTED]:~ echo hi there!
 hi there!
 [EMAIL PROTECTED]:~ echo hi there\!
 hi there\!
 [EMAIL PROTECTED]:~ echo hi there!
 hi there!
 [EMAIL PROTECTED]:~ echo hi there\!
 hi there!

This looks perfectly fine to me. The ! is treated just like any other
non-special character.

Re: inconsistent treatment of backslash-bang

[pk]

On Friday 18 July 2008 07:35, Lawrence D'Oliveiro wrote:

 pk wrote:
 
 This is documented in man bash, and only happens in interactive shells
 (not scripts).
 
 I just tried putting my six cases into a script, and I get exactly the
 same sort of output as interactively.

On my system, I get this:

$ echo !
-bash: !: event not found
$ bash -c 'echo !'
!

Is your system configured properly?

Re: inconsistent treatment of backslash-bang

[pk]

On Wednesday 16 July 2008 04:47, Lawrence D'Oliveiro wrote:

 Description:
 In all contexts in which a character X has special meaning to bash, it
 should be possible to insert that character literally by writing \X.
 This fails in one case: where X is !, and the context is inside double
 quotes.

That is documented in man bash, and only appens in interactive shells (not
scripts). You can disable history expansion (set +H, set +o histexpand) to
avoid the problem, or use \! outside double quotes.

Re: builtin printf not printing unicode characters?

[pk]

On Sunday 11 May 2008 04:16, Chet Ramey wrote:

 pk wrote:
 The man page says that bash builtin printf supports the standard
 printf(1) formats. But it seems that \u is not working:
 
 $ /usr/bin/printf '\u212b\n'
 Å
 $ printf '\u212b\n'
 \u212b
 
 Am I doing something wrong here?
 
 The `\u' format string escape is not standard.  I will consider it for a
 future enhancement.

Ah ok, I was fooled by the fact that printf(1) on my system does include the
\u format.

Thanks

Re: for ... in ... do ignores escape characters

[pk]

On Friday 18 April 2008 14:02, Dave Rutherford wrote:

 Quotes or escapes in the output of the `` are input to the shell rather
 than shell syntax, so won't be interpreted.  You just need to quote more.
 
 $ foo () { echo sony; echo apple; echo hewlett packard; }
 
 Now note the difference between:
 
 $ for w in `foo`; do echo $w; done
 sony apple hewlett packard

This assigns sony, apple, hewlett and packard to $w.

 $ for w in `foo`; do echo $w; done
 sony
 apple
 hewlett
 packard

Same as above, but $w is quoted (which does not change anything in this
case).

 $ for w in `foo`; do echo $w; done
 sony
 apple
 hewlett packard

This assigns

sony
apple
hewlett packard

as a single value to $w. Note that the for loop is executed only once. This
is not what the OP wanted.

Re: for ... in ... do ignores escape characters

[pk]

On Friday 18 April 2008 14:02, Dave Rutherford wrote:

 Quotes or escapes in the output of the `` are input to the shell rather
 than shell syntax, so won't be interpreted.  You just need to quote more.
 
 $ foo () { echo sony; echo apple; echo hewlett packard; }
 
 Now note the difference between:
 
 $ for w in `foo`; do echo $w; done
 sony apple hewlett packard

This assigns 

sony
apple
hewlett packard

as a single value to $w. Since $w is not quoted in the echo statement,
format is lost. The for loop is executed only once.

 $ for w in `foo`; do echo $w; done
 sony
 apple
 hewlett
 packard

This assigns sony, apple, hewlett, and packard in turn to $w. $w is
quoted in the echo statement (which does not change anything in this
case, since the values do not contain spaces).

 $ for w in `foo`; do echo $w; done
 sony
 apple
 hewlett packard

This assigns

sony
apple
hewlett packard

as a single value to $w, and format is preserved because $w is quoted in the
echo statement. Note that the for loop is executed only once. This
is not what the OP wanted.