gmane.comp.shells.bash.help

Re: How to extrapolate string including '~'?

Greg Wooledge — 2013-05-13T16:22:54

$ str='";date;: "'
$ eval x=\"$str\"
Mon May 13 12:17:17 EDT 2013

Eval is very, very easy to use wrong.  eval x=\"$str\" would be an example
of doing it wrong.

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

Re: How to extrapolate string including '~'?

John Kearney — 2013-05-13T16:10:46

I think you meant
eval x=\"$str\"


On Sun, May 12, 2013 at 2:35 PM, Peng Yu <pengyu.ut-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: hi, doubt about xargs

Greg Wooledge — 2013-05-13T13:04:46

Since you have -print0, you may also have -execdir.  If so, then this
becomes somewhat simpler:

wooledg< at >wooledg:/tmp/greg$ mkdir -p a/b/c
wooledg< at >wooledg:/tmp/greg$ touch a/b/c/foo.txt
wooledg< at >wooledg:/tmp/greg$ find . -name '*.txt' -execdir sh -c 'for f; do cp "$f" "${f%.txt}.bak"; done' _ {} +
wooledg< at >wooledg:/tmp/greg$ ls -l a/b/c
total 0
-rw-r--r-- 1 wooledg wooledg 0 May 13 08:59 foo.bak
-rw-r--r-- 1 wooledg wooledg 0 May 13 08:59 foo.txt

Without -execdir, your script would have to extract the directory name
and filename of each path argument, cd into the directory, and then do
its work.  Something like this:

find . -name '*.txt' -exec sh -c 'for f; do dir=${f%/*} file=${f##*/}; cd "$dir" || continue; cp "$file" "${file%.txt}.bak"; cd -; done' _ {} +

hi, doubt about xargs

Joaquin Villanova — 2013-05-13T10:09:13

Hi, i want to convert all my existing pdf documents to djvu (just to 
give a brief intro) then i decided to use bash shell and find / xargs, 
so i executed the following
find ~/ -name '*pdf*' -print0 | xargs -0  -n 1 pdf2djvu -i '{}' -o '{}'

In pdf2djvu -i goes for input and -o for output. The issue here is that 
i want to get the output to the same directories to the inputfile, but 
with this order all what i get is one output file only, thanks in advance!

Re: How to extrapolate string including '~'?

Greg Wooledge — 2013-05-13T12:41:16

See the thread starting at
http://lists.gnu.org/archive/html/bug-bash/2013-04/msg00046.html

I believe this was forked from a previous discussion thread, but the
first thread is eluding me at the moment.

Re: Does bash support ENHANCED FEATURES in re_format(7)?

Greg Wooledge — 2013-05-13T12:35:51

GNU/Linux extensions to the POSIX standards for regular expression
syntax are not guaranteed to work in all applications.

For what it's worth, the re_format(7) man page in Debian 6.0 does not
even have an "ENHANCED FEATURES" section.  Neither does the re_format(7)
in Debian wheezy (upcoming 7.0).


Obviously not.

Does bash support ENHANCED FEATURES in re_format(7)?

Peng Yu — 2013-05-13T03:19:20

Hi,

re_format(7) says (under ENHANCED FEATURES)
117            \d  Matches a digit character.  This is equivalent to
`[[:digit:]]'.


The following code shows that '\d' does not work. Does bash support
these ENHANCED FEATURES in re_format(7)?

~/linux/test/bash/man/pattern/[[:digit:]]$ ./main.sh
x=123
echo "${x//[[:digit:]]}"

echo "${x//\d}"
123

~/linux/test/bash/man/pattern/[[:digit:]]$ cat main.sh
#!/usr/bin/env bash

set -v
x=123
echo "${x//[[:digit:]]}"
echo "${x//\d}"

How to extrapolate string including '~'?

Peng Yu — 2013-05-12T12:35:34

Hi,

I want to extrapolate a string that includes '~'. Is there a way to do
so in bash?

str='~'
x=$(eval "$str")
-bash: /Users/john: Is a directory

Re: BASH quotation question...

Barry Smith — 2013-05-12T03:51:07

John:

Thank you for the pointer.

I remembered immediately the brackets when I saw them, but I'll have
to refresh my memory by looking through some of my notes on them

Thank you for the pointer.

Peace,
--
Barry Smith
c 704-497-4217
e bnsmith001-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org
skype bnsmith001_gmail
w1 http://bit.ly/l8QJup
w2 http://scs-llc.info/


On Sat, May 11, 2013 at 10:25 PM, John Kearney <dethrophes-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: BASH quotation question...

John Kearney — 2013-05-12T02:25:36

you need

STARTDIR="/cygdrive/c/Users/
Barry/Douments"
cd "$STARTDIR"

SRC="Work_Week_2012.09.12"
TARGET="Work\ Week\ 2012.09.12"
mkdir "$TARGET"

i.e. quote the variables when you use them.

and its not a bad idea to get into the habit of writting it more like this

mkdir "${TARGET}"


cheers



On Sat, May 11, 2013 at 9:38 PM, Barry Smith <bnsmith001-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: BASH quotation question...

Roman Rakus — 2013-05-11T22:28:14

You can follow my golden rule: double-quote every (not only) variable 
expansion.
It means, whenever you have dollar sign in your script encapsulate it to 
double quotes.
example:
var=foo
echo "$var"

It will be doing what you want in 99% of situations.

RR

On 05/11/2013 09:38 PM, Barry Smith wrote:

BASH quotation question...

Barry Smith — 2013-05-11T19:38:46

I just found this "help list" mentioned on
http://tiswww.case.edu/php/chet/bash/bashtop.html . There were no
instructions on subscribing, so I haven't subscribed, and might never
know if there are followup responses.  Please reply to the list
archive, and CC me on responses.

HELP please, oh gods of bash!
Thank you in advance.

My environment is Windows 7 Home Premium / cygwin / Bash 4.1.10(4)-release.

I am writing a "simple" bash script to set up for a backup to DVD, but
am having problems setting variables to directory names with spaces,
and then using the variables in mkdir / cp / mv / rm / md5sum
commands.

Here is the nuts and bolts of the second script that does a md5sum,
cp, check after cp, then rm.  I have coded an exit that I will move
down the script as I test.

Current logic fail -- the "mkdir" is creating multiple directories
(due to the spaces in the name), not just ONE directory with spaces in
the directory name.
---
#!/bin/bash
# Proper header for a Bash script.

STARTDIR="/cygdrive/c/Users/B

Re: Different completion behavior for ':' when there are other files or not

Chet Ramey — 2013-05-09T20:43:44

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/9/13 1:01 AM, Chris Down wrote:

Your second case, after adding a second file, is not the same as the
original report.

- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet-oNH6vCZdlc4< at >public.gmane.org    http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGMCoAACgkQu1hp8GTqdKso1gCgjuXaei0BIpREZ6a3KZLlMq/3
WhAAmwfAq43GRVebvWd/dhBxqCaxEp18
=5Cz3
-----END PGP SIGNATURE-----

Re: Different completion behavior for ':' when there are other files or not

Chet Ramey — 2013-05-09T20:42:46

It's not that unexpected if you think about what's going on.  First, `:'
is one of the characters that splits words for the readline completion
code.  (That list of characters is in $COMP_WORDBREAKS.)  That means
that the word being completed is "".  When there is a single file in the
directory, that (`:') is returned as the one completion.  The `:' is
quoted because the colon is special to the completion code, as explained
above, and bash needs to distinguish it so that it does not break words.
The trailing slash is probably added by your completion function; I don't
get that when running bash without any completions defined.



`Correctly', I assume, means that nothing happens.  The same null word
completion happens as above, but there are multiple possible completions
so nothing is added to the line.

This has come up in the past.  Read the thread at

http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00163.html

for a sample.

In short, there isn't a bug, and there isn't anything mysterious happening

Re: Different completion behavior for ':' when there are other files or not

Chris Down — 2013-05-09T05:01:38

I can reproduce this, with the caveat that in my case it *doesn't* fix itself
when there are other files:

    $ echo $BASH_VERSION
    4.2.45(2)-release
    $ mkdir :
    $ cd :\:/
    bash: cd: ::/: No such file or directory
    $ > foo
    $ cd :\:/
    bash: cd: ::/: No such file or directory

Chris

Different completion behavior for ':' when there areother files or not

Peng Yu — 2013-05-09T04:00:30

Hi,

In /tmp/a, there is only ':', but nothing else.

/tmp/a$ mkdir :
/tmp/a$ cd :<TAB>

The command completion of the above one becomes the following (which
is not correct).

/tmp/a$ cd :\:/

But if I create an addition file, then the command completion of 'cd
:<TAB>' will work correctly.
/tmp/a$ touch xxx.txt

Is it a bug in bash? Or I need to somehow configure bash correctly?

Re: safe parsing of configuration files?

adrelanos — 2013-05-08T15:13:45

Thanks! I am going to test this.

John Kearney:

Github is indeed not very visible for this kind of stuff.

Bash wiki might be more helpful to more people.

http://wiki.bash-hackers.org/howto/conffile

Re: safe parsing of configuration files?

John Kearney — 2013-05-07T20:50:09

forgot this is help-bash.
the first version is more portable but if you only need it on bash you can
actually just do this

  ks_cgf_Src() {
    local LC_COLLATE=C
    local cline_tmp
    local vval_tmp
    local tmp_quotes="'\""
    while IFS= read -r cline_tmp ; do
      case "${cline_tmp}" in
        \#* | '') ;;  # skip empty lines and commented lines
        [a-zA-Z_]*=*)
          vval_tmp=${cline_tmp#*=}
          vval_tmp=${vval_tmp#[${tmp_quotes}]}
          vval_tmp=${vval_tmp%[${tmp_quotes}]}
          printf -v "${cline_tmp%%=*}" "%s" "${vval_tmp}"
          ;;
        *)echo "skipping '${cline_tmp}'"
          ;;
      esac
    done
  }




On Tue, May 7, 2013 at 10:31 PM, John Kearney <dethrophes-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: safe parsing of configuration files?

John Kearney — 2013-05-07T20:31:34

not sure if its worth putting it on github,

anyway I tested this one briefly

ks_val_ChkName() {
    case "${1:?Missing Variable Name}" in
      [!a-zA-Z_]* | *[!a-zA-Z_0-9]* | '' ) return 3;;
    esac
  }
    ks_val_Set() {
        ks_val_ChkName "${1}" || return $?
        eval "${1}"'="${2}"'
    }

  ks_cgf_Src() {
    local LC_COLLATE=C
    local cline_tmp
    local vval_tmp
    local tmp_quotes="'\""
    while IFS= read -r cline_tmp ; do
      case "${cline_tmp}" in
        \#* | '') ;;  # skip empty lines and commented lines
        [a-zA-Z_]*=*)     # *[![:space:]]*) # non empty lines
          vval_tmp=${cline_tmp#*=}
          vval_tmp=${vval_tmp#[${tmp_quotes}]}
          vval_tmp=${vval_tmp%[${tmp_quotes}]}
          ks_val_Set "${cline_tmp%%=*}" "${vval_tmp}" || echo "error
'${cline_tmp}'"
          #printf "%s=%q\n" "${cline_tmp%%=*}" "${vval_tmp}"
          ;;
        *)echo "skipping '${cline_tmp}'"
          ;;
      esac
    done
  }

declare | grep "^te"
  ks_cgf_Src <<EOF

test=kkkk
te=k

Re: safe parsing of configuration files?

adrelanos — 2013-05-07T06:57:12

John Kearney:

I get a error.
./extest: line 18: syntax error near unexpected token `;'
./extest: line 18: `      case "${cline_tmp}" ; in'

Since this has been said to be impossible with bash, you could polish it
a bit please and perhaps put it on github?

Re: Where is $TERM documented?

Greg Wooledge — 2013-05-06T12:55:07

In addition to what the others have already told you, TERM is the index
into a terminal capabilities database, which is handled by your operating
system.  There are two competing terminal capabilities database standards,
of course (this is Unix, after all).  BSD systems use "termcap", and
SysV systems use "terminfo".  On many modern systems, such as Linux,
the operating system uses one of these natively and emulates the other
for compatibility.

"xterm-256color" sounds new-ish, so you're probably on Linux, and you're
probably using the terminfo implementation that comes with ncurses.  But
that's just a guess.

Typically the REAL question in these cases is something like "I'm sshing
to a remote host and it says unknown terminal type".  In that case, what
you need to do is:

 1. Find out which terminal database the remote host is using (termcap
    or terminfo).
 2. Find an uncompiled terminal database entry for your terminal type.
    This is relatively easy if your local system uses the same database
    as