Re: Multi-word matching in history expansion
Reply addresses set by hand to work around broken defaults. (Again.) Paul Jarc wrote: The Wanderer <[EMAIL PROTECTED]> wrote: !ls /h How about: ls /h That works, and explains what exactly that function is supposed to do (I have inadvertently gotten into that mode at various points in the past, but was never able to figure out what it was for). I'm still not comfortable with it, and would greatly prefer to be able to use ! expansion as was once possible, but I suspect that that is simply a matter of what I am personally accustomed to; I can see nothing on which to base a plausibly objective argument that this is less convenient than the form I would prefer. So: I'm not precisely satisfied, but this should suffice if necessary. Thank you. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
CDPATH bug
Dear Sir, I would like to bring your attention to a long lasting bash bug. It exists in the most recent (3.2.15) and could reproduce it as far back as with SUSE 9.1 (don't have the shell in front of me to verify version). It is very reproducible: DrWho:~-> echo $CDPATH ~/work:~/work/HOL DrWho:~-> ls Desktop bin opera6.html work DrWho:~-> cd Desktop DrWho:~/Desktop-> cd ../ DrWho:~-> bash Ctags are up to date DrWho:~-> cd ./Desktop DrWho:~/Desktop-> cd ../ DrWho:~-> sh DrWho:~-> cd Desktop sh: cd: Desktop: No such file or directory DrWho:~-> echo $CDPATH ~/work:~/work/HOL DrWho:~-> CDPATH="" DrWho:~-> cd Desktop DrWho:~/Desktop-> exit Exit DrWho:~-> which sh /bin/sh DrWho:~-> The strange thing is that sh is just a link to bash, and starting a bash subshell works fine. Thanks, Nikos Valkanas Billing Services Technology & Operations Tel: +30 213 000 4087 hellas online Adrianiou 2, 11525 Athens, www.hol.gr IMPORTANT NOTICE: This email and any of its attachments and information contained herein are intended only for the recipient(s) named above and are privileged, confidential, protected by law and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons, is prohibited and may constitute a criminal offence. hellas online cannot accept any responsibility for the accuracy or completeness of this message as it may have been transmitted over a public network. P Please consider your environmental responsibility before printing this e-mail
Re: CDPATH bug
On 10/1/07, Valkanas Nikos <[EMAIL PROTECTED]> wrote: > > The strange thing is that sh is just a link to bash, and starting a bash > subshell works fine. > This is because : "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well". from http://www.gnu.org/software/bash/manual/bashref.html#SEC85 19. If `CDPATH' is set, the `cd' builtin will not implicitly append the current directory to it. This means that `cd' will fail if no valid directory name can be constructed from any of the entries in `$CDPATH', even if the a directory with the same name as the name given as an argument to `cd' exists in the current directory. Pierre
Re: CDPATH bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pierre Gaston on 10/1/2007 6:02 AM: > from http://www.gnu.org/software/bash/manual/bashref.html#SEC85 > > 19. If `CDPATH' is set, the `cd' builtin will not implicitly append > the current directory to it. This means that `cd' will fail if no > valid directory name can be constructed from any of the entries in > `$CDPATH', even if the a directory with the same name as the name > given as an argument to `cd' exists in the current directory. Which is a bug in bash, because POSIX requires cd to behave as though CDPATH implicitly ended with a directive for `.'. http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html (also read the amended instructions at http://www.opengroup.org/austin/interps/uploads/40/6230/AI-037.txt) step 5 deals with CDPATH, and states: "repeat this step with the next pathname in CDPATH until all pathnames have been tested." at which point, if CDPATH did not find a solution, the implementation MUST move on to step 6: "Set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAOZ784KuGfSFAYARAhi6AJ9CQjwsvQalQOyfSICXm8R7rxwlWQCg14Zm Ct0zY1qcET5LbrQsDB6wTHY= =9F2W -END PGP SIGNATURE-
RE: CDPATH bug
Dear Pierre, I am afraid you didn't understand my problem. I think it is a bug. I am not trying to use CDPATH or prepend any directory to my destination. I am simply trying to go down a subdirectory and it won't go, despite the subdirectory being valid: DrWho:~-> ls Desktop bin opera6.html work DrWho:~-> sh DrWho:~-> cd Desktop sh: cd: Desktop: No such file or directory DrWho:~-> cd ./Desktop DrWho:~/Desktop-> exit exit DrWho:~-> The problem with that is that I use CDPATH and it is a valid VARIABLE in bash. However, whenever I try to compile anything, make will use -sh and all Cds will fail unless they are declared fully. I am not expecting CDPATH to work with -sh. I am simply saying that "cd Desktop" should work with "any shell* - including sh (or bash's emulation of sh). According to me correct sh behavior would be in this case to ignore any inherited CDPATHs but keep cd functionality intact. Regards, Nikos Valkanas Billing Services Technology & Operations Tel: +30 213 000 4087 hellas online Adrianiou 2, 11525 Athens, www.hol.gr IMPORTANT NOTICE: This email and any of its attachments and information contained herein are intended only for the recipient(s) named above and are privileged, confidential, protected by law and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons, is prohibited and may constitute a criminal offence. hellas online cannot accept any responsibility for the accuracy or completeness of this message as it may have been transmitted over a public network. P Please consider your environmental responsibility before printing this e-mail -Original Message- From: Eric Blake [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 3:23 PM To: Pierre Gaston Cc: Valkanas Nikos; bug-bash@gnu.org Subject: Re: CDPATH bug -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pierre Gaston on 10/1/2007 6:02 AM: > from http://www.gnu.org/software/bash/manual/bashref.html#SEC85 > > 19. If `CDPATH' is set, the `cd' builtin will not implicitly append > the current directory to it. This means that `cd' will fail if no > valid directory name can be constructed from any of the entries in > `$CDPATH', even if the a directory with the same name as the name > given as an argument to `cd' exists in the current directory. Which is a bug in bash, because POSIX requires cd to behave as though CDPATH implicitly ended with a directive for `.'. http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html (also read the amended instructions at http://www.opengroup.org/austin/interps/uploads/40/6230/AI-037.txt) step 5 deals with CDPATH, and states: "repeat this step with the next pathname in CDPATH until all pathnames have been tested." at which point, if CDPATH did not find a solution, the implementation MUST move on to step 6: "Set curpath to the string formed by the concatenation of the value of PWD, a slash character, and the operand." - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAOZ784KuGfSFAYARAhi6AJ9CQjwsvQalQOyfSICXm8R7rxwlWQCg14Zm Ct0zY1qcET5LbrQsDB6wTHY= =9F2W -END PGP SIGNATURE-
Re: CDPATH bug
On 10/1/07, Valkanas Nikos <[EMAIL PROTECTED]> wrote: > > Dear Pierre, > > I am afraid you didn't understand my problem. I think I did, if bash is invoked as sh, it behaves differently, one of these differences is that cd will not try to search in you current directory. as soon as CDPATH is set, "cd Desktop" will only work if Desktop is in a subdir of the directories defined in CDPATH and will fail even if Desktop is in your current dir. This behaviour is documented in the reference guide read again my first mail. It seems that this documented behaviour is a "bug" because POSIX doesn't define it this way. I tend to agree with Erik on this point. Now the sh, I have around me now behave like bash (ash, solaris' /bin/sh and /usr/xgp4/bin/sh) Pierre
RE: CDPATH bug
Thanks. If I understand correctly you will follow up on this. Just to stress, this is not some "perk". It took me a while to figure out that CDPATH was the culprit, and not been able to use make has been a major headache, since I am using gentoo. Nikos Valkanas Billing Services Technology & Operations Tel: +30 213 000 4087 hellas online Adrianiou 2, 11525 Athens, www.hol.gr IMPORTANT NOTICE: This email and any of its attachments and information contained herein are intended only for the recipient(s) named above and are privileged, confidential, protected by law and/or contain trade secrets. Any unauthorized use, e.g. review, printing, copying or distribution by other persons, is prohibited and may constitute a criminal offence. hellas online cannot accept any responsibility for the accuracy or completeness of this message as it may have been transmitted over a public network. P Please consider your environmental responsibility before printing this e-mail -Original Message- From: Pierre Gaston [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 4:22 PM To: Valkanas Nikos Cc: bug-bash@gnu.org Subject: Re: CDPATH bug On 10/1/07, Valkanas Nikos <[EMAIL PROTECTED]> wrote: > > Dear Pierre, > > I am afraid you didn't understand my problem. I think I did, if bash is invoked as sh, it behaves differently, one of these differences is that cd will not try to search in you current directory. as soon as CDPATH is set, "cd Desktop" will only work if Desktop is in a subdir of the directories defined in CDPATH and will fail even if Desktop is in your current dir. This behaviour is documented in the reference guide read again my first mail. It seems that this documented behaviour is a "bug" because POSIX doesn't define it this way. I tend to agree with Erik on this point. Now the sh, I have around me now behave like bash (ash, solaris' /bin/sh and /usr/xgp4/bin/sh) Pierre
ulimit block size
We received a bug report[1] against bash-3.2 in Fedora 7, where the reporter states that ulimit in bash is using a block size of 1024 vs. 512 which is in the opengroup standard[2]. What the upstream position on this? [1] https://bugzilla.redhat.com/show_bug.cgi?id=314461 [2] http://www.opengroup.org/onlinepubs/95399/utilities/ulimit.html http://www.opengroup.org/onlinepubs/009695399/functions/ulimit.html Thanks ~p -- Pete Graner <[EMAIL PROTECTED]> Base Operating Systems Red Hat Inc.
Re: ulimit block size
> We received a bug report[1] against bash-3.2 in Fedora 7, where the > reporter states that ulimit in bash is using a block size of 1024 vs. > 512 which is in the opengroup standard[2]. > > What the upstream position on this? I'll take a look. If bash is using 1024 while in posix mode, it's a bug. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: ulimit block size
On 10/1/07, Chet Ramey <[EMAIL PROTECTED]> wrote:
> > We received a bug report[1] against bash-3.2 in Fedora 7, where the
> > reporter states that ulimit in bash is using a block size of 1024 vs.
> > 512 which is in the opengroup standard[2].
> >
> > What the upstream position on this?
>
> I'll take a look. If bash is using 1024 while in posix mode, it's a bug.
>
Looking I don't see where is could be changed based on POSIX, according to:
bash-3.2/builtins/ulimit.def:
static RESOURCE_LIMITS limits[] = {
#ifdef RLIMIT_CORE
{ 'c',RLIMIT_CORE, 1024, "core file size", "blocks" },
#endif
~p
--
Pete Graner <[EMAIL PROTECTED]>
Base Operating Systems
Red Hat Inc.
Re: Multi-word matching in history expansion
(And again.) Bob Proulx wrote: The Wanderer wrote: Quite some time and several varyingly-significant updates of bash ago, I was able to perform history expansion on multi-word commands. At present and for some while now, [!ls /h] instead expands to ls /tmp/ /h This is also what csh does in this situation too. This type of history substitution originated with csh and it would be the standard against which other implementations would be compared. That makes a certain amount of sense, although the behaviour itself still does not. What does csh do with e.g. !ls\ /h (that is, attempting to escape the space so as to prevent tokenizing them separately)? I do not have csh installed, so I can't test. I know that bash simply gives bash: !ls\: event not found which would appear to imply this sort of expansion either takes place before tokenization or does not use standard tokenization rules, so the obvious first-attempt-at-a-workaround approach of escaping the token separator is ineffective. But I don't know the code history of this feature in bash. I would be interested to find out, if someone is present who does know. I would also be interested to know the rationale behind the behaviour, given that the only potentially real-world scenario I can think of where this behaviour seems as if it would be useful is in adding e.g. the '-g' flag to the end of a compiler command line, but the other behaviour was useful to me in a wide variety of circumstances. I would also be curious to know the exact reason why escaping the space does not cause it to be treated as part of the initial command to be matched and so form an effective workaround, but I suspect that there is no practical way to explain that better than is done by the source itself. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
error message of ${A:?} and ${A?} should be different
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux machine 2.6.21-1-686 #1 SMP Sat May 26 16:14:59 UTC 2007
i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 0
Release Status: release
Description:
[EMAIL PROTECTED]:/tmp/x/bash-3.2$ echo ${A?}
bash: A: parameter null or not set
[EMAIL PROTECTED]:/tmp/x/bash-3.2$ echo ${A:?}
bash: A: parameter null or not set
[EMAIL PROTECTED]:/tmp/x/bash-3.2$ A=
[EMAIL PROTECTED]:/tmp/x/bash-3.2$ echo ${A:?}
bash: A: parameter null or not set
[EMAIL PROTECTED]:/tmp/x/bash-3.2$ echo ${A?}
I don't like the first error message. It should say something like
"bash: A: parameter not set", because I have omitted the colon.
Repeat-By:
See description.
Fix:
--- subst.c.orig2007-10-02 00:28:55.0 +0200
+++ subst.c 2007-10-02 00:30:55.0 +0200
@@ -267,7 +267,7 @@
static WORD_DESC *parameter_brace_expand_word __P((char *, int, int));
static WORD_DESC *parameter_brace_expand_indir __P((char *, int, int, int *,
int *));
static WORD_DESC *parameter_brace_expand_rhs __P((char *, char *, int, int,
int *, int *));
-static void parameter_brace_expand_error __P((char *, char *));
+static void parameter_brace_expand_error __P((char *, char *, int));
static int valid_length_expression __P((char *));
static intmax_t parameter_brace_expand_length __P((char *));
@@ -5050,8 +5050,9 @@
used as the error message to print, otherwise a standard message is
printed. */
static void
-parameter_brace_expand_error (name, value)
+parameter_brace_expand_error (name, value, check_nullness)
char *name, *value;
+ int check_nullness;
{
WORD_LIST *l;
char *temp;
@@ -5065,7 +5066,12 @@
dispose_words (l);
}
else
-report_error (_("%s: parameter null or not set"), name);
+{
+ if (check_nullness)
+report_error (_("%s: parameter null or not set"), name);
+ else
+report_error (_("%s: parameter not set"), name);
+}
/* Free the data we have allocated during this expansion, since we
are about to longjmp out. */
@@ -6259,7 +6265,7 @@
}
else if (c == '?')
{
- parameter_brace_expand_error (name, value);
+ parameter_brace_expand_error (name, value, check_nullness);
return (interactive_shell ? &expand_wdesc_error :
&expand_wdesc_fatal);
}
else if (c != '+')
Function visibility
I have several functions in my /etc/profile (Mac OSX 10.4.9). I can use the functions at the commandline, however inside of scripts I receive an error. I'll use an example of a function I have called cecho that echo's a string in a color that is passed in $2, $1 has the string: ./maintenance: line 27: cecho: command not found If I run this from the command line, it works fine. What am I doing wrong? I also have the same problem with any alias commands I use inside of scripts. If I type 'set' on the CLI it lists all of the functions. Should I use export function-name? TIA TonyB -- View this message in context: http://www.nabble.com/Function-visibility-tf4551985.html#a12990189 Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Function visibility
On Monday 01 October 2007, retiredff wrote: > I have several functions in my /etc/profile (Mac OSX 10.4.9). I can use the > functions at the commandline, however inside of scripts I receive an error. > I'll use an example of a function I have called cecho that echo's a string > in a color that is passed in $2, $1 has the string: > > ./maintenance: line 27: cecho: command not found > > If I run this from the command line, it works fine. What am I doing wrong? > I also have the same problem with any alias commands I use inside of > scripts. If I type 'set' on the CLI it lists all of the functions. scripts are not interactive shells so you wouldnt have the same environment as an interactive shell ... so you need to place the definitions of functions into a file and have the script source that at start > Should I use export function-name? that would only help when you executed the script from a shell which sourced the /etc/profile and not if it were run through say a cronjob -mike signature.asc Description: This is a digitally signed message part.
Re: Function visibility
On Monday 01 October 2007, retiredff wrote: > I have several functions in my /etc/profile (Mac OSX 10.4.9). I can use > the > functions at the commandline, however inside of scripts I receive an > error. > I'll use an example of a function I have called cecho that echo's a string > in a color that is passed in $2, $1 has the string: > > ./maintenance: line 27: cecho: command not found > > If I run this from the command line, it works fine. What am I doing wrong? > I also have the same problem with any alias commands I use inside of > scripts. If I type 'set' on the CLI it lists all of the functions. scripts are not interactive shells so you wouldnt have the same environment as an interactive shell ... so you need to place the definitions of functions into a file and have the script source that at start > Should I use export function-name? that would only help when you executed the script from a shell which sourced the /etc/profile and not if it were run through say a cronjob -mike Thanks mike. It's been awhile since I programmed in Bash. I remember now.. -- View this message in context: http://www.nabble.com/Function-visibility-tf4551985.html#a12990931 Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Multi-word matching in history expansion
The Wanderer wrote: > (And again.) > > Bob Proulx wrote: > >> The Wanderer wrote: >> >>> Quite some time and several varyingly-significant updates of bash >>> ago, I was able to perform history expansion on multi-word >>> commands. >>> >>> At present and for some while now, [!ls /h] instead expands to >>> >>> ls /tmp/ /h >> >> This is also what csh does in this situation too. This type of >> history substitution originated with csh and it would be the standard >> against which other implementations would be compared. > > That makes a certain amount of sense, although the behaviour itself > still does not. > > What does csh do with e.g. > > !ls\ /h > > (that is, attempting to escape the space so as to prevent tokenizing > them separately)? I do not have csh installed, so I can't test. Bash imitates the csh behavior, and csh does not honor the escape. > I would be interested to find out, if someone is present who does know. > I would also be interested to know the rationale behind the behaviour, > given that the only potentially real-world scenario I can think of where > this behaviour seems as if it would be useful is in adding e.g. the '-g' > flag to the end of a compiler command line, but the other behaviour was > useful to me in a wide variety of circumstances. It's a feature that was first implemented in csh, and bash attempts to mimic the csh behavior. > I would also be curious to know the exact reason why escaping the space > does not cause it to be treated as part of the initial command to be > matched and so form an effective workaround, but I suspect that there is > no practical way to explain that better than is done by the source itself. Because history expansion simply does not honor backslash quoting in that context, and whitespace delimits the history event. It's no more complicated (and no simpler) than that. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: CDPATH bug
Valkanas Nikos wrote: > Thanks. If I understand correctly you will follow up on this. > > Just to stress, this is not some "perk". It took me a while to figure > out that CDPATH was the culprit, and not been able to use make has been > a major > headache, since I am using gentoo. Regardless of whether or not this behavior is counter to what Posix.2 currently says (and it probably is), you could have done: CDPATH=. make to achieve the desired effect. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: CDPATH bug
Pierre Gaston wrote: > I think I did, if bash is invoked as sh, it behaves differently, one > of these differences is that > cd will not try to search in you current directory. > as soon as CDPATH is set, "cd Desktop" will only work if Desktop is in a > subdir > of the directories defined in CDPATH and will fail even if Desktop is > in your current dir. > > This behaviour is documented in the reference guide read again my first mail. > > It seems that this documented behaviour is a "bug" because POSIX > doesn't define it this way. I tend to agree with Erik on this point. I have not made up my mind about it. The bash behavior when invoked as `sh' (or in posix mode) is the historical sh behavior, and is what other shells claiming posix compliance (ksh93, dash) or as close as you can get to a straight-line descendant of the bourne shell (SVR2 sh, SVR3 sh, SVR4.2 sh) do. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Offset error (when using PS1 with colors and newline)
On 2007-07-12 Andreas Schwab wrote:
> > 1. Set PS1="\033[01;37m[ \[\033[01;34m\]\w\[\033[00m\]
> > \033[01;37m]\n\$\033[00m "
>
> You need to bracket _every_ nonprinting sequence of characters with \[\].
I've asked you before, but you've not answered, or it got lost.
What nonprinting sequence is not escaped above?
And is there anything unescaped in the testcase below?
1. PS1="\n\[\033[0m\]"
2. Type "ls ./_ /foo" ("_" => cursor)
3. Press TAB twice, where the "_" is above
Result:
ls ./ /foo
[...]
ls ./ /foo_
(where "_" is the cursor again)
I've just tested this with bash 3.2.25(1).
For reference, the bug has been reported at launchpad:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/119938
--
http://daniel.hahler.de/
signature.asc
Description: This is a digitally signed message part.
