Re: No tilde expansion right after a quotation
Eric Blake wrote:
> According to Angel Tsankov on 2/15/2009 3:02 PM:
>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>> expansions just to be on the safe side, though I think home
>> directories may not contain spaces.)
>
> There are some contexts, such as variable assignments, where double
> quotes are not necessary.
>
> foo='a b'
> bar=$foo
>
> is just as safe as
>
> bar="$foo"
>
> In fact, it is MORE portable to avoid double quotes in assignments,
> if you are worried about writing scripts portable to more than just
> bash. Of these two constructs:
>
> foo="`echo "a b"`"
> bar=`echo "a b"`
>
> only the setting of bar is guaranteed to parse correctly in all
> shells.
Eric, thanks for youy replay. If double quotes are not that portable, then
how am I suppose to assign the output from some command to a variable when
the output contains a space?
-Angel
Re: No tilde expansion right after a quotation
Angel Tsankov wrote:
> Eric Blake wrote:
>> According to Angel Tsankov on 2/15/2009 3:02 PM:
>>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>>> expansions just to be on the safe side, though I think home
>>> directories may not contain spaces.)
>> There are some contexts, such as variable assignments, where double
>> quotes are not necessary.
>>
>> foo='a b'
>> bar=$foo
>>
>> is just as safe as
>>
>> bar="$foo"
>>
>> In fact, it is MORE portable to avoid double quotes in assignments,
>> if you are worried about writing scripts portable to more than just
>> bash. Of these two constructs:
>>
>> foo="`echo "a b"`"
>> bar=`echo "a b"`
>>
>> only the setting of bar is guaranteed to parse correctly in all
>> shells.
> Eric, thanks for youy replay. If double quotes are not that portable, then
> how am I suppose to assign the output from some command to a variable when
> the output contains a space?
Word splitting doesn't happen on assignments, so:
$ var=$(echo "foo bar baz")
$ echo "$var"
foo bar baz
--
D.
Re: No tilde expansion right after a quotation
Dave B wrote: > Angel Tsankov wrote: >> Eric, thanks for youy replay. If double quotes are not that >> portable, then how am I suppose to assign the output from some >> command to a variable when the output contains a space? > > Word splitting doesn't happen on assignments, so: > > $ var=$(echo "foo bar baz") > $ echo "$var" > foo bar baz Hmm, thanks for pointing this out. -Angel
Re: Help: Bash script that show you the last file created?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 2/15/2009 9:44 PM:
>> ctime is the time when the inode was last modified, not (necessarily)
>> the time when the file was created.
>
> if op is worried about that, then there is no place where the exact creation
> time can be found. the interpretation of {c,m}time is up to how the op is
> backing things up, and is for him to figure out what is best. he's asked for
> guidance on sorting things, and ls will give him that.
Newer file systems provide Btime (birth time) in addtion to [acm]time, and
while not all OSs support it yet, at least some BSD flavors and cygwin 1.7
do. GNU findutils is able to find files based on Btime, given sufficient
OS and file system support; so although many systems cannot find files
based on creation time, there exist some that can.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmZYMMACgkQ84KuGfSFAYBBswCglSzYhUkyhAWCKSq05e1VqNZb
QW8An3NiQUrQKVwvjIw9q3kKVNmOxYZd
=a3GV
-END PGP SIGNATURE-
Re: No tilde expansion right after a quotation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Angel Tsankov on 2/16/2009 2:26 AM: >> There are some contexts, such as variable assignments, where double >> quotes are not necessary. >> >> foo="`echo "a b"`" >> bar=`echo "a b"` >> >> only the setting of bar is guaranteed to parse correctly in all >> shells. > Eric, thanks for youy replay. If double quotes are not that portable, then > how am I suppose to assign the output from some command to a variable when > the output contains a space? The portability bug I am referring to is the use of double-quoted back-ticks containing a double quote. Some (buggy) shells require you to use \" instead of " inside backticks if the overall backtick expression is double-quoted. So finding contexts where word splitting does not occur (such as variable assignment and case statements) and avoiding double quotes in those particular contexts makes it easier to write arbitrary backtick expressions. For more details, see: http://www.gnu.org/software/autoconf/manual/autoconf.html#Shell-Substitutions But besides the "`""`" bug, double quotes are safe in all contexts, and you are free to use them even in contexts where they add no protection. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmZYeQACgkQ84KuGfSFAYBPzQCgq2vkBd6o6QtVzcUKsTUTsA/N qgQAoJadvlYysc9SiWm9VeLp+S+hFOz6 =AiK6 -END PGP SIGNATURE-
Re: "unset HISTFILESIZE" not working in .bashrc
> Actually, what I want is to prevent writing to the history file > at all when bash exits. (Not all the time, just in certain cases > that other logic in .bashrc will be able to detect. Unsetting > HISTFILESIZE unconditionally was a simplified test case.) > > Should I unset HISTFILE, or set it to /dev/null, instead of > trying to mess with HISTFILESIZE? The "official" way to prevent the history from being written is to unset HISTFILE. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://tiswww.tis.case.edu/~chet/
Re: No tilde expansion right after a quotation
Eric Blake wrote: > The portability bug I am referring to is the use of double-quoted > back-ticks containing a double quote. Some (buggy) shells require you to > use \" instead of " inside backticks if the overall backtick expression is > double-quoted. Hence this statement in Posix: Either of the following cases produces undefined results: * A single-quoted or double-quoted string that begins, but does not end, within the "`...`" sequence * A "`...`" sequence that begins, but does not end, within the same double-quoted string -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
autocd in bash-4.0-rc1
Hi,
The autocd option is a long awaited bash feature.
Unfortunately I dislike the noisy impementation
which prints every time "cd ".
Due to the fact that autocd is off by default
everyone who actives the option should know what s/he
is doing and does not need a nanny.
If it is not accecptable to make the default behaivor quiet
please apply my patch.
Thanks
Markus
diff -ru bash-4.0-rc1/builtins/shopt.def bash-4.0-rc1.patched/builtins/shopt.def
--- bash-4.0-rc1/builtins/shopt.def 2009-01-04 20:32:23.0 +0100
+++ bash-4.0-rc1.patched/builtins/shopt.def 2009-02-16 08:57:37.964912464
+0100
@@ -83,6 +83,7 @@
extern int gnu_error_format;
extern int check_jobs_at_exit;
extern int autocd;
+extern int autocdquiet;
extern int glob_star;
#if defined (EXTENDED_GLOB)
@@ -132,6 +133,7 @@
shopt_set_func_t *set_func;
} shopt_vars[] = {
{ "autocd", &autocd, (shopt_set_func_t *)NULL },
+ { "autocdquiet", &autocdquiet, (shopt_set_func_t *)NULL },
{ "cdable_vars", &cdable_vars, (shopt_set_func_t *)NULL },
{ "cdspell", &cdspelling, (shopt_set_func_t *)NULL },
{ "checkhash", &check_hashed_filenames, (shopt_set_func_t *)NULL },
diff -ru bash-4.0-rc1/execute_cmd.c bash-4.0-rc1.patched/execute_cmd.c
--- bash-4.0-rc1/execute_cmd.c 2009-01-04 20:32:29.0 +0100
+++ bash-4.0-rc1.patched/execute_cmd.c 2009-02-16 08:46:23.340492392 +0100
@@ -99,6 +99,7 @@
extern int posixly_correct;
extern int expand_aliases;
extern int autocd;
+extern int autocdquiet;
extern int breaking, continuing, loop_level;
extern int parse_and_execute_level, running_trap;
extern int command_string_index, line_number;
@@ -3660,6 +3661,11 @@
xtrace_print_word_list (words, 0);
goto run_builtin;
}
+ if (autocdquiet && interactive && words->word && is_dirname
(words->word->word))
+{
+ words = make_word_list (make_word ("cd"), words);
+ goto run_builtin;
+}
if (command_line == 0)
command_line = savestring (the_printed_command_except_trap);
diff -ru bash-4.0-rc1/shell.c bash-4.0-rc1.patched/shell.c
--- bash-4.0-rc1/shell.c2009-01-04 20:32:41.0 +0100
+++ bash-4.0-rc1.patched/shell.c2009-02-16 07:59:42.348138201 +0100
@@ -149,6 +149,7 @@
/* Non-zero means to change to a directory name supplied as a command name */
int autocd = 0;
+int autocdquiet = 0;
/* Tells what state the shell was in when it started:
0 = non-interactive shell script
--
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
Re: "unset HISTFILESIZE" not working in .bashrc
Chet Ramey wrote: > HISTFILESIZE doesn't exist until bash tries to load the history > list from the history file (taken from $HISTFILE). At that point, > if it doesn't have a value, it's set to $HISTSIZE. That doesn't > happen until after the startup files are read, as you guessed. > > If you want to avoid history file truncation, your best bet is > to set HISTFILESIZE to some very large value. Actually, what I want is to prevent writing to the history file at all when bash exits. (Not all the time, just in certain cases that other logic in .bashrc will be able to detect. Unsetting HISTFILESIZE unconditionally was a simplified test case.) Should I unset HISTFILE, or set it to /dev/null, instead of trying to mess with HISTFILESIZE?
Re: Bash with colors?
Antonio Macchi wrote: >>> commands like "ls --color" does not use terminfo capabilities... >> >>> ...use instead fixed strings (without regards about TERMinal) >>> is this a good (and safe) choice too? >> >> IMHO not. Too many assumptions. GNU ls seems to always assume an ANSI >> terminal, regardless which TERM is set. Or did I miss something? > I have done a little search about how terminals uses "setaf" > a very very long list of terminals uses the same style of capabilities > are maybe the others simply "out-of-date"? No wonder, 'setaf' is "set ANSI foreground" IIRC, dedicated to ANSI terminal control. But yes, you're right, most terminals talk ANSI, at least for the most important codes. And for the same reason some people hardcode the dot or the comma as thousands separator in their code, ignoring locale settings. "Never seen something different." Alone the fact that STDOUT is a terminal, without knowing which terminal it is, isn't a good base for a decision what to send. I remember alot of stupid MS-DOS applications that blindly relied on running ANSI.SYS CON driver - producing screen output that looked like streusel slices. Just my 2ct J.
Re: Bash with colors?
And for the same reason some people hardcode the dot or the comma as thousands separator in their code, ignoring locale settings. "Never seen something different." what's the best? hardcoding, improving efficiency, and putting another brick on the wall of standardization.. ...or i18n/TERMinalization, improve complexity (and bug-risk), slow down performance and consolidation of the differences I can't answer to that question... but I see a lot of bash-code using hardcoding http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html http://tldp.org/LDP/abs/html/colorizing.html#AEN19341 may be, in the future, terminal differencies will disappear...
cancel
This message was cancelled from within Mozilla.
