Re: Function visibility
On Mon, Oct 01, 2007 at 04:43:15PM -0700, 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. Should I > use export function-name? [...] /etc/profile ~/.profile are not shell customization files, they are your login session customization file. They are read once only upon login, so you may only put there customization that will be affecting all future processes (no necessarily shells) in your session. bash's customization files are ~/.bashrc and depending on how bash was compiled /etc/bashrc or /etc/bash.bashrc... see your manual. bash has a bug/misfeature in that the login shells, even when interactive, don't load the bashrc. To work around that, you have to do things like this in /etc/profile: if [ -n "$BASH_VERSION" ]; then case $- in *i*) if [ -f /etc/bashrc ] && [ -r /etc/bashrc ]; then . /etc/bashrc fi;; esac fi And do something similar in your ~/.profile for your ~/.bashrc. -- Stéphane
RE: CDPATH bug
Sorry for butting in. Considering that "Desktop" is a valid subdir is it normal behavior in *any* shell to get: DrWho:~-> cd Desktop sh: cd: Desktop: No such file or directory Which shell behaves like that? Even if one would argue that CDPATH should not be set in sh, normal shell behaviour dictates to ignore any variables it doesn't handle. Handling a variable it shouldn't is one mistake. Handling it wrongly is a second one. 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: Chet Ramey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 5:04 AM To: Pierre Gaston Cc: Valkanas Nikos; bug-bash@gnu.org Subject: 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: CDPATH bug
Thanks for the tip. The problem was spending 2 days to find that CDPATH was the problem. Since then I no longer have a problem. There are many ways to handle it. I can also start a subshell and unset CDPATH just for the make. I am surprised it hasn't come up before. 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: Chet Ramey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 4:49 AM To: Valkanas Nikos Cc: Pierre Gaston; bug-bash@gnu.org Subject: 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
On 10/2/07, Valkanas Nikos <[EMAIL PROTECTED]> wrote: > Sorry for butting in. Considering that "Desktop" is a valid subdir is it > normal behavior in *any* shell to get: > > DrWho:~-> cd Desktop > sh: cd: Desktop: No such file or directory > > Which shell behaves like that? Chet Ramey listed some in his mail, I've tried: ash, ksh93 and pdksh when invoked with the name "sh", /bin/sh and /usr/xpg4/bin/sh under sunOS 5.8 They all behave like bash when started with the name "sh" > Even if one would argue that CDPATH should not be set in sh CDPATH is documented in sh, so there is no reason not to use it, but so far the only "sh" I found that cd to a subdir in the current path when CDPATH is set is zsh when started with the name "sh".
RE: CDPATH bug
You are right. I am starting to think that /bin/sh implementation is correct and bash implementation is too permissive. If I set CDPATH: export CDPATH=".:~/work:~/work/HOL" everything will work correctly with all shells, and be much more analogous to PATH. However, the analogy to PATH should not be exact. PATH will not work with an empty PATH, whereas cd should work with empty CDPATH. Maybe bash should be aligned to the other shells (i.e. no cd to a subdir unless "." is part of CDPATH, or CDPATH is not set) 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: Pierre Gaston [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 11:37 AM To: Valkanas Nikos Cc: bug-bash@gnu.org Subject: Re: CDPATH bug On 10/2/07, Valkanas Nikos <[EMAIL PROTECTED]> wrote: > Sorry for butting in. Considering that "Desktop" is a valid subdir is it > normal behavior in *any* shell to get: > > DrWho:~-> cd Desktop > sh: cd: Desktop: No such file or directory > > Which shell behaves like that? Chet Ramey listed some in his mail, I've tried: ash, ksh93 and pdksh when invoked with the name "sh", /bin/sh and /usr/xpg4/bin/sh under sunOS 5.8 They all behave like bash when started with the name "sh" > Even if one would argue that CDPATH should not be set in sh CDPATH is documented in sh, so there is no reason not to use it, but so far the only "sh" I found that cd to a subdir in the current path when CDPATH is set is zsh when started with the name "sh".
Re: Multi-word matching in history expansion
(And yet again. Not that it did a lot of good last time; I *still* got an incorrect private reply, in addition to the public one. Is there any particular reason why you ignored my explicit request to not get both responses?) Chet Ramey wrote: The Wanderer wrote: (And again.) Bob Proulx wrote: 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 expected as much. 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. That's the rationale for doing it in bash, but not the rationale for doing it at all. 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. That's not a reason; that's just a description of the behaviour. I want to know *why* it does not honor it, and as I said, probably the only effective way to find that out is to read the source. (For the technical "why", at least. For the theoretical "why", it reduces to the same question about the rationale, above.) -- 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.
the bug mailing lists are open bug reporting lists (Re: Multi-word matching in history expansion)
The Wanderer wrote: > (And yet again. Not that it did a lot of good last time; I *still* got > an incorrect private reply, in addition to the public one. Even though it is not an official standard the best ad-hoc standard is to set "Mail-Followup-To: " to instruct mailers where to send followup messages. It would be beneficial if you added that header to your mail messages because then mailers could do the right thing automatically. I saw that you had set Reply-To: back to the mailing list and I do not know why that reply message did not respect your reply-to header. For what it is worth I think it should have done so. > Is there any particular reason why you ignored my explicit request > to not get both responses?) First let me say thanks for being so understanding of the time and energy that volunteers and maintainers devote to this project. We make a lot more forward progress when we work together instead of fighting among ourselves. And now a few words about the GNU bug reporting mailing lists... The GNU bug mailing lists are open and there is no expectation that bug reporters are subscribed in order to post bug reports. This makes bug reporting mailing lists fundamentally different than discussion mailing lists where everyone is expected to be subscribed. In a discussion mailing list always sending to the mailing list is usual and private replies done when purposefully taking discussion off of the public list. But in a bug reporting mailing list where bug reporters usually report bugs without being subscribed then it is usual to followup both to the mailing list and to the original sender. A problem that I frequently see is that a bug reporter will post a problem to a bug reporting mailing list. I can verify that the poster is not subscribed and no indication was made that they read the mailing lists through any other interface. Someone takes the time to post a nicely worded reply that exactly addresses their issue but sends it only to the mailing list. Now I am in a quandary. I know with a high degree of confidence that the original poster did not see any response to their bug. As far as they are concerned their bug went into a black hole. That is bad. How should I respond? Should I forward the discussion to the original poster and also to the mailing list so that the action is coordinated with the group and someone else does not do the same thing again? Do I just replicate the discussion in my own words and act as if I did not see it and simply respond to the original poster? There is no easy solution in that case. Better if the original bug reporter can get the responses directly. The guideline I use for initial responses is to group reply so that messages go to both the original poster and to the bug list. This is almost always the best general course of action. Anything other than this would require additional information and resources. Then on subsequent messages I trim off all addresses except the bug list and the initial bug reporter. The responders obviously were subscribed in order to have read and responded to the message and only the original poster is unknown whether they are subscribed or not. (Unless the original poster included a Mail-Followup-To: header and if so then the mail client will respect it and do what it instructs, usually directly back to the mailing list, in which case I have nothing to trim.) If I happen to recognize that the poster is subscribed then I trim off that address from the response as well. But I think this can at best be viewed as an extra-credit and opportunistic nicety. It definitely takes more time and effort and particularly for busy maintainers I would rather see them devote their energy to working on the project code rather than spending a large amount of time on mailing list niceties. If we can help them out a little here then everyone wins. Bob
Re: Function visibility
Stephane Chazelas wrote: > To work around that, you have to do things like this in > /etc/profile: > ... > And do something similar in your ~/.profile for your ~/.bashrc. While that is normal to do to configure interactive sessions the original question was where should shell functions be placed for use by scripts. I think the above answer is a good answer but to a different question. It reads as if this is a suggestion to place shell functions in a bashrc file and I wanted to clarify that that is not the case. Non-interactive scripts should not normally be reading system or personal bashrc customization files. Putting a function in a bashrc would still not make it visible to scripts. This of the problems that scripts would have if user's aliases for ls='ls -F --color=always' and rm='rm -i' were seen by scripts. Script authors need a known stable run environment. In summary shell functions should be defined in the script or defined in a file sourced by the script. Bob
Re: Function visibility
On Tue, Oct 02, 2007 at 10:57:16AM -0600, Bob Proulx wrote: > Stephane Chazelas wrote: > > To work around that, you have to do things like this in > > /etc/profile: > > ... > > And do something similar in your ~/.profile for your ~/.bashrc. > > While that is normal to do to configure interactive sessions the > original question was where should shell functions be placed for use > by scripts. I think the above answer is a good answer but to a > different question. [...] Oops, I had indeed missed that important part of the discussion, you're completely right. However note that the file pointed to by the BASH_ENV environment variable is sourced even by non-interactive shells (as long as bash is not called as "sh" or with --posix or with POSIXLY_CORRECT or SHELLOPTS=posix in its environment) So, putting function definitions in /some/file will make those function available to all non-posix bash instances that receive BASH_ENV=/some/file in their environment. Now, I'd agree with you you probably don't want to do that, and the most sensible thing is to source your shell function library file from your script. -- Stéphane
Re: Offset error (when using PS1 with colors and newline)
dAniel hAhler wrote: 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? Two occurrences of "\033[01;37m]". -- Matthew There's no place like ~.
Re: Function visibility
Stephane Chazelas wrote:
> However note that the file pointed to by the BASH_ENV
> environment variable is sourced even by non-interactive shells
And while that feature can be useful it can also break working
scripts. Therefore I try to ignore that this feature exists and hope
that no one (ab)uses it.
The AT&T ksh uses $ENV for the same purpose but does not automatically
source a kshrc file. Therefore a very common configuration for the
typical user in their profile is to set ENV=$HOME/.kshrc and use it
for all of the same things that we use a bashrc file. But this
creates problems for '#!/bin/ksh' scripts that then have $ENV set
because for ksh even non-interactive scripts source $ENV.
The documented way to avoid this problem is to conditionally set the
value of ENV. The Bolsky & Korn, The KornShell documents this
following snippet.
export ENV='${FILE[(_$-=0)+(_=1)-_${-%%*i*}]}'
export FILE=$HOME/.kshrc
That version had some problems though and I used this alternative to
work around them.
export ENV='${START[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'
export START=$HOME/.kshrc
The worst part is that the user is responsible to configure this
correctly. Incorrectly done and this breaks scripts that would
otherwise work fine. Because $ENV is sourced before the script is
executed it is quite difficult for the script to workaround.
The point of all of this is that this particular feature may sound
like a good idea but in practice has caused problems and we have the
experience of using these other shells to learn from here. Look at
the complexity added by the above. The experience was not good and
IMNHO it is better to avoid the feature.
> (as long as bash is not called as "sh" or with --posix or with
> POSIXLY_CORRECT or SHELLOPTS=posix in its environment)
One reason that although I prefer bash as my command shell I always
use '#!/bin/sh' for scripts. The benefits of a standard environment
outweigh the benefits of nice features most of the time. When I need
or want the feature then of course I use '#!/bin/bash' as required.
> So, putting function definitions in /some/file will make those
> function available to all non-posix bash instances that receive
> BASH_ENV=/some/file in their environment.
Shh... Don't tell anyone. Someone will (ab)use it. :-)
> Now, I'd agree with you you probably don't want to do that, and
> the most sensible thing is to source your shell function library
> file from your script.
Agreed.
Bob
Re: Function visibility
On Tue, Oct 02, 2007 at 01:43:05PM -0600, Bob Proulx wrote:
[...]
> The AT&T ksh uses $ENV for the same purpose but does not automatically
> source a kshrc file. Therefore a very common configuration for the
> typical user in their profile is to set ENV=$HOME/.kshrc and use it
> for all of the same things that we use a bashrc file. But this
> creates problems for '#!/bin/ksh' scripts that then have $ENV set
> because for ksh even non-interactive scripts source $ENV.
>
> The documented way to avoid this problem is to conditionally set the
> value of ENV. The Bolsky & Korn, The KornShell documents this
> following snippet.
>
> export ENV='${FILE[(_$-=0)+(_=1)-_${-%%*i*}]}'
> export FILE=$HOME/.kshrc
[...]
Note however that it's no longer true of ksh93 and it's not true
of many newer versions of ksh88 as that is a POSIX
non-conformance, so you should no longer need that kludge
nowadays.
And note that POSIX shs are meant to handle $ENV when
interactive and the above code is not POSIX conformant (but it's
not likely to cause any problem).
[...]
> > (as long as bash is not called as "sh" or with --posix or with
> > POSIXLY_CORRECT or SHELLOPTS=posix in its environment)
>
> One reason that although I prefer bash as my command shell I always
> use '#!/bin/sh' for scripts. The benefits of a standard environment
> outweigh the benefits of nice features most of the time. When I need
> or want the feature then of course I use '#!/bin/bash' as required.
When I need a feature that a POSIX shell can't provide, then
generally that means I need something more like perl or
python...
Note that #! /bin/sh will not always give you a POSIX shell.
Sometimes, it may give you an ancient shell that your Unix
vendor keeps there for backward compatibility. "sh" has been a
lot of different shells along Unix history...
--
Stéphane
Re: the bug mailing lists are open bug reporting lists (Re: Multi-word matching in history expansion)
Bob Proulx wrote: > I saw that you had set Reply-To: back to the mailing list and I do not > know why that reply message did not respect your reply-to header. > For what it is worth I think it should have done so. I changed it. I've been burned in the past (or at least received complaints) when I send "official" bash or readline responses to only the list, or to only the submitter. I now send everything of general interest to both the submitter and the list as a matter of personal policy. 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: Multi-word matching in history expansion
The Wanderer wrote: >>> 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. > > That's the rationale for doing it in bash, but not the rationale for > doing it at all. That particular decision was made 30 years ago, and I doubt Bill Joy is interested in revisiting it. > >>> 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. > > That's not a reason; that's just a description of the behaviour. I want > to know *why* it does not honor it, and as I said, probably the only > effective way to find that out is to read the source. Because the code that looks for the delimiter marking the end of the history event looks for whitespace characters, and does not skip the next character when it encounters a backslash. I'm really not sure how much more the source code will elucidate the point; the implementation is fairly obvious from a description of the behavior. 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: > Sorry for butting in. Considering that "Desktop" is a valid subdir is it > normal behavior in *any* shell to get: > > DrWho:~-> cd Desktop > sh: cd: Desktop: No such file or directory > > Which shell behaves like that? Ummm...did you read my previous reply? Just about every shell that supports CDPATH will produce this result if CDPATH doesn't contain `.' or the empty string. 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: > Maybe bash should be aligned to the other shells (i.e. no cd to > a subdir unless "." is part of CDPATH, or CDPATH is not set) I'm comfortable with the current behavior. 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: the bug mailing lists are open bug reporting lists (Re: Multi-word matching in history expansion)
Bob Proulx wrote: The Wanderer wrote: (And yet again. Not that it did a lot of good last time; I *still* got an incorrect private reply, in addition to the public one. Even though it is not an official standard the best ad-hoc standard is to set "Mail-Followup-To: " to instruct mailers where to send followup messages. It would be beneficial if you added that header to your mail messages because then mailers could do the right thing automatically. I do not remember having ever heard of this header. If I have, it would have been in previous discussions with people on bug-coreutils (almost certainly including yourself), which are in my archives for reference against the day someone writes a mail client which I would find usable which supports this header. If I have assurance that mail clients which are in widespread use will respect this header, I may start using it instead of Reply-To. However, as long as that is so far the more widely supported of the two as I suspect it is, I am very unlikely to switch. Having to set *two* extra headers by hand, in addition to having to set the To header which in a properly configured environment would be set correctly automatically, would simply be adding insult to metaphorical injury. I would, despite this, have in fact set both headers on this message, were it not for the fact that I do not remember offhand how to add a custom (== "not in the list which is available by default") header to a message in Mozilla Mail, and some cursory exploration does not turn it up. I saw that you had set Reply-To: back to the mailing list and I do not know why that reply message did not respect your reply-to header. For what it is worth I think it should have done so. My guess, based on the fact that the reply was not only sent both to me and to the list but also Cc:ed to the sender, would be that the individual changed the headers by hand. Is there any particular reason why you ignored my explicit request to not get both responses?) First let me say thanks for being so understanding of the time and energy that volunteers and maintainers devote to this project. We make a lot more forward progress when we work together instead of fighting among ourselves. I know, and I agree, and I do apologize for seeming belligerent and being disruptive; on the offtopic issue of reply headers, this is an matter about which I feel strongly, and on the on-topic issues, my limited experience seems to indicate that unless one is very lucky only being disproportionately persistent gives one any chance of getting a non-dismissive answer. It is (and though this sounds melodramatic it is true) a source of intermittent pain to me that I am not, and am in fact unlikely ever to be, in a position to actually contribute anything useful to almost any of the projects in which I am interested - much less all of the ones I actually use. And now a few words about the GNU bug reporting mailing lists... The GNU bug mailing lists are open and there is no expectation that bug reporters are subscribed in order to post bug reports. This makes bug reporting mailing lists fundamentally different than discussion mailing lists where everyone is expected to be subscribed. In a discussion mailing list always sending to the mailing list is usual and private replies done when purposefully taking discussion off of the public list. But in a bug reporting mailing list where bug reporters usually report bugs without being subscribed then it is usual to followup both to the mailing list and to the original sender. The sample I have seen would not seem to support that last claim, though I will admit that the sample I have seen is not necessarily representative. I do not necessarily consider it reasonable to support bug reports made from non-subscribing persons, but I can see some potentially valid arguments in favor of that position. However, I maintain quite firmly and against any and all evidence to the contrary that any reply to any message posted to any discussion forum should by default go back to that forum, *only*, and that in any forum in which this does not occur the defaults are broken. I further make the definition that any mailing list to which subscribers can post constitutes a discussion forum. (A mailing list to which non-subscribers can post, all the more so - although it may be something else as well, and there may be room for somewhat different rules to govern that additional thing ) A problem that I frequently see is that a bug reporter will post a problem to a bug reporting mailing list. I can verify that the poster is not subscribed and no indication was made that they read the mailing lists through any other interface. Someone takes the time to post a nicely worded reply that exactly addresses their issue but sends it only to the mailing list. Now I am in a quandary. I know with a high degree of confidence that the original poster did not see any response to their bug. As far as
Re: Function visibility
Stephane Chazelas wrote: Note that #! /bin/sh will not always give you a POSIX shell. Sometimes, it may give you an ancient shell that your Unix vendor keeps there for backward compatibility. THANK YOU! It's nice to know I'm not the only one laboring under wrong the notion that /bin/sh is always Posix. Which is not to say I don't wish that such OS's (*cough*Solaris*cough*) wouldn't get their act together and stop such nonsense, but... -- Matthew There's no place like ~.
Any plans to integrate an XML parser
Hi Chet, others, In our bash scripts, we often access XML files. Are there any plans to integrate an XML parser in bash? For example, merge into the main tree the following bash patch? http://home.eol.ca/~parkw/index.html#expat Thank you, -- Nicholas Sushkin, Senior Software Engineer www.openfinance.com www.wealthinformationexchange.com
Re: Function visibility
Stephane Chazelas wrote: > Note however that it's no longer true of ksh93 and ... > Note that #! /bin/sh will not always give you a POSIX shell. Note that #!/bin/ksh won't always give you a ksh93 shell either. At least one system (*cough*HP-UX*cough*) still ships ksh88 there. Bob
Re: Offset error (when using PS1 with colors and newline)
Matthew Woehlke 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? > > Two occurrences of "\033[01;37m]". I see now. Thanks for pointing at it. Fixing the PS1 above still triggers the bug, if you use "ls ./_ /fo" though. Please note that the PS1 above does not come from me, but from a bug comment. There seems to be an issue Can you reproduce the bug with PS1="\n\[\033[0m\]" (which seems to be valid as far as I can see)? I can trigger the misplacement of the cursor there with just "ls ./", followed by tab-tab, while PS1="\[\033[0m\]\n" works. It seems to get triggered by a newline and following non-printable characters.
