With fresh 9.1 install, bash completion no longer expands $HOME
On my 9.0-based machines, if I typed $HOME[tab] when typing a command in bash, the $HOME would be overwritten by the actual path to my home directory (the value of $HOME) and tab completion would work as expected. After a fresh 9.1 install, this does not work as well. $HOME is still detected by completion, but it is not expanded after pressing tab (this does not matter to me), but also an extra space is inserted after tab. For example, if I have a directory named src under my home directory, and my working directory is an unrelated directory, and I type cd $HOME/sr[tab]: Under 9.0: cd /home/dcaldwell/src/[cursor] Under 9.1: cd $HOME/src [cursor] So under 9.1 I lose the slash and see a space instead, essentially, which renders this not very useful. If I use ~ rather than $HOME, it works correctly under both. Obviously I could probably learn to type ~ rather than $HOME but it would be a hard habit to break after years. :) For bash (and for most software) I am using binary packages from the -release distribution, so my 9.0 machines have 4.1.11 and my 9.1 machines have 4.2.37. I don't know enough about all the moving parts to know where to start tracking this down, so can someone point me in the right direction? (Unless there's an known problem or change I'm missing.) I can't figure out where completion is configured in bash outside the /usr/local/etc/bash_completion.d/ directory, which incidentally on my 9.1 setup contains: $ ls /usr/local/etc/bash_completion.d/ dbus-bash-completion.sh*gdbus-bash-completion.sh* gsettings-bash-completion.sh* Thanks, -- David Caldwell http://www.davidpcaldwell.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Coredumps settings for user programm
Hello! Tell me please, can i setting coredumps write mechanism for write only stack of programm and current frame? -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: With fresh 9.1 install, bash completion no longer expands $HOME
Re: http://lists.freebsd.org/pipermail/freebsd-questions/2013-June/251607.html This has nothing to do with FreeBSD 9.0 vs. 9.1 other than the fact that the package on 9.0 is older than 9.1. Instead, this has everything to do with the difference between bash versions you're using. Remember: packages and ports 99% of the time are third-party software (in this case GNU), and therefore any changes in behaviour between versions are entirely independent of FreeBSD. The feature you like from bash 4.1 was removed in some manner of speaking in bash 4.2. This prompted a user to complain -- please read the thread (not just the post) in full, because you will see there are others who *do not* like this behaviour: http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html In bash 4.2.29 -- which is technically patch 029 for bash 4.2 -- the feature you desire got moved into a shopt feature called direxpand, with the default being disabled. Because bash 4.3 is not out yet, you will not find any mention of this in the official bash CHANGES file at this time. Instead, you will find the answer in the official bash42-029 patch itself (read the top): ftp://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-029 If you do not like this default, or feel strongly about this whole thing and want to discuss it, the GNU bug-bash mailing list is the place: http://www.gnu.org/software/bash/ To enable direxpand, use shopt -s direxpand. You can put this command in your ~/.bashrc. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[SOLVED] Re: www/179397: I used mouse focus in open-motif and shift-click3 to iconify xterms, doing so causes cursor to disappear and mouse is unusable!
According to freebsd-gnats-sub...@freebsd.org on Fri, 06/07/13 at 06:40:
Thank you very much for your problem report.
It has the internal identification `www/179397'.
The individual assigned to look at your
report is: freebsd-www.
You can access the state of your problem report at any time
via this link:
http://www.freebsd.org/cgi/query-pr.cgi?pr=179397
Category: www
Responsible:freebsd-www
Synopsis: I used mouse focus in open-motif and shift-click3 to iconify
xterms, doing so causes cursor to disappear and mouse is unusable!
Arrival-Date: Fri Jun 07 10:40:00 UTC 2013
I may be one of the few people left who use x11-toolkits/open-motif on
the FreeBSD desktop, but be that as it may, there is a bug that needs
to be fixed in the /usr/ports/x11-servers/xorg-server/files/ directory.
In May 2013 this directory included this file:
-rw-r--r-- 1 root wheel 3487 May 2 13:08 extra-dix_events.c
I upgraded my ports on a nearly identical system on May 23 and
again on June 5th of 2013:
unix% ll /usr/ports/x11-servers/xorg-server/files/
total 40
drwxr-xr-x 2 root wheel 1024 Jun 5 11:20 .
drwxr-xr-x 4 root wheel 512 Jun 5 12:06 ..
-rw-r--r-- 1 root wheel 402 Jun 5 11:20
extra-Xserver-hw-xfree86-os-support-bsd-sparc64_video.c
-rw-r--r-- 1 root wheel 350 Jun 5 11:20 extra-Xserver-os-xprintf.c
-rw-r--r-- 1 root wheel 5536 May 23 12:19 extra-arch-ia64
-rw-r--r-- 1 root wheel 438 May 23 12:19 extra-arch-powerpc
-rw-r--r-- 1 root wheel 2467 Jun 5 11:20 extra-clang
-rw-r--r-- 1 root wheel 799 May 23 12:19 extra-include_eventstr.h
-rw-r--r-- 1 root wheel 493 Jun 5 11:20 extra-new-arch-i386
-rw-r--r-- 1 root wheel 511 Jun 5 11:20 extra-old-arch-i386
-rw-r--r-- 1 root wheel 645 Jun 5 11:20 extra-os-utils.c
-rw-r--r-- 1 root wheel 320 Jun 5 11:20 extra-servermd.h
-rw-r--r-- 1 root wheel 384 May 23 12:19
patch-Xserver-hw-xfree86-common-xf86Config.c
-rw-r--r-- 1 root wheel 469 May 23 12:19
patch-Xserver-hw-xfree86-os-support-bsd-i386_video.c
-rw-r--r-- 1 root wheel 471 May 23 12:19 patch-xorgconf.cpp
-rw-r--r-- 1 root wheel 155 May 23 12:19 pkg-deinstall.in
-rw-r--r-- 1 root wheel 551 May 23 12:19 pkg-install.in
The lack of the extra-dix_events.c patch file caused using my three
button USB mouse with x11-toolkits/open-motif to fail. Note: all ports
were rebuilt on Jun 5th after running svn update /usr/ports from within
/usr/ports.
Once the mouse failed, all I could do was CTRL-ALT-BS and revert to
virtual terminals - not a very good desktop substitute.
It turns out that the last patch segment of extra-dix_events.c was omitted
(along with the entire patch file itself):
@@ -3632,7 +3583,8 @@ CheckPassiveGrabsOnWindow(
{
FixUpEventFromWindow(device, xE, grab-window, None, TRUE);
- TryClientEvents(rClient(grab), device, xE, count, mask,
+ TryClientEvents(rClient(grab), device, xE, count,
+GetEventFilter(device, xE),
GetEventFilter(device, xE), grab);
}
The lack of this last patch segment was the cause of my problems with mwm
(part of the x11-toolkits/open-motif port) but it did not impact other
window managers such as FVWM which may be why this patch was overlooked.
Regards,
web...
--
William Bulley Email: w...@umich.edu
72 characters width template -|
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Suddenly Seeing Clamav Errors After MailScanner Update
I am working on a FBSD 9.1-STABLE mail machine that's been working fine. After upgrading to MailScanner 4.84.5_3, we are now suddenly seeing like this: Clamd::ERROR:: UNKNOWN CLAMD RETURN ./lstat() failed: Permission denied. ERROR :: /var/spool/MailScanner/incoming/68340 Any ideas what might cause this? I have fallen back to the previous MailScanner.conf file wherein the problem does NOT seem to happen. But, after diffing old and new config files I cannot see where anything relevant to this might have changed. Ideas anyone? -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: buildworld selectively?
On Sun, 09 Jun 2013 21:08:23 -0400, Robert Huff wrote: Walter Hurry writes: Fair enough. Point taken, thanks. Nevertheless I see no reason to compile stuff I neither want nor need. While I endorse the principle ... it can be difficult for the casual user to know which parts can be removed without blowing up things they want. (Been there, had to change the underwear after the new kernel didn't boot. Booted old kernel, fixed things.) Wise words. The kernel and world builds/installs went fine, but soon afterwards I noticed a problem with the mail/dcc-dccd port (required, in my case, by SpamAssassin), which would not rebuild, complaining that the base sendmail was not found or too old. Since I use Postfix, I had set WITHOUT_SENDMAIL in /etc/src.conf. I shall remove it and rebuild. C'est la vie! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Bourne shell if syntax
script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then echo $PTR /path/to/PTR_absent.txt fi === output for an IP: a-b-c-d.domain.net. [: a-b-c-d.domain.net.: unexpected operator thanks Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then -- Devin echo $PTR /path/to/PTR_absent.txt fi === output for an IP: a-b-c-d.domain.net. [: a-b-c-d.domain.net.: unexpected operator thanks Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of dte...@freebsd.org Sent: Monday, June 10, 2013 11:59 AM To: lcon...@go2france.com; freebsd-questions@freebsd.org Cc: Devin Teske Subject: RE: Bourne shell if syntax -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then err, that should have been: or if [ ! $PTR ]; then -- Devin but _NOT_ if [ $PTR == ]; then -- Devin echo $PTR /path/to/PTR_absent.txt fi === output for an IP: a-b-c-d.domain.net. [: a-b-c-d.domain.net.: unexpected operator thanks Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
On 06/10/2013 01:53 PM, lcon...@go2france.com wrote: script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then echo $PTR /path/to/PTR_absent.txt fi === output for an IP: a-b-c-d.domain.net. [: a-b-c-d.domain.net.: unexpected operator Try this instead and see if this fixes it: if [ _$PTR == _ ] ; then --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
On 06/10/2013 01:59 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then I work across a bunch of different OSs and shells of many vintages. As I recall, the -z argument has problems of portability on older/broken shells and/or is not available in all environments (I cannot recall which at the moment). So I achieve the same results by using a character sentinel that guarantees that the comparison always works: f [ _$PTR == _ ] ; then -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
On Mon, 10 Jun 2013 14:05:45 -0500, Tim Daneliuk tun...@tundraware.com wrote: if [ _$PTR == _ ] ; then I've never seen this syntax before. Intriguing! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:06 PM To: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 01:59 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then I work across a bunch of different OSs and shells of many vintages. As I recall, the -z argument has problems of portability on older/broken shells and/or is not available in all environments (I cannot recall which at the moment). So I achieve the same results by using a character sentinel that guarantees that the comparison always works: f [ _$PTR == _ ] ; then Character sentinels are not required. FreeBSD's sh(1) knows (because [ is a built-in) that when you quote a parameter, that it is not (even if the value begins with -) not an operator. So doing things like: foo=-gt if [ $foo = ]; then or foo=-gt if [ -z $foo ]; then or if [ ! $foo ]; then or even the following (flipping the conditional): if [ $foo != ]; then if [ -n $foo ]; then if [ $foo ]; then All work as expected. It matters not the value of $foo. sh(1) in FreeBSD knows because of the double-quotes that it is not an operator. Furthermore... == is not the right operator. It's =. Portability would surely be compromised if you were using == (which doesn't work on FreeBSD; or many other OSes I gather from experience). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
On 06/10/2013 02:10 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:06 PM To: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 01:59 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then I work across a bunch of different OSs and shells of many vintages. As I recall, the -z argument has problems of portability on older/broken shells and/or is not available in all environments (I cannot recall which at the moment). So I achieve the same results by using a character sentinel that guarantees that the comparison always works: f [ _$PTR == _ ] ; then Character sentinels are not required. FreeBSD's sh(1) knows (because [ is a built-in) that when you quote a parameter, that it is not (even if the value begins with -) not an operator. That wasn't really my point. I use sentinels because in the face of an empty string this: if [ $PTR = ] Actually evaluates to: if [ = ] Which throws an error. The character sentinel avoids this without having to use -z, which as I said, I've had problems with not being too portable across older machinery. All work as expected. It matters not the value of $foo. sh(1) in FreeBSD knows because of the double-quotes that it is not an operator. Furthermore... == is not the right operator. It's =. Portability would surely be compromised if you were using == (which doesn't work on FreeBSD; or many other OSes I gather from experience). Ooops, I did catch that and you're quite right. -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:17 PM To: dte...@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 02:10 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:06 PM To: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 01:59 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then I work across a bunch of different OSs and shells of many vintages. As I recall, the -z argument has problems of portability on older/broken shells and/or is not available in all environments (I cannot recall which at the moment). So I achieve the same results by using a character sentinel that guarantees that the comparison always works: f [ _$PTR == _ ] ; then Character sentinels are not required. FreeBSD's sh(1) knows (because [ is a built-in) that when you quote a parameter, that it is not (even if the value begins with -) not an operator. That wasn't really my point. I use sentinels because in the face of an empty string this: if [ $PTR = ] Actually evaluates to: if [ = ] and hence why you shouldn't do that. Instead do this: if [ $PTR = ] Which [potentially] evaluates to: if [ = ] Which throws an error. The character sentinel avoids this without having to use -z, which as I said, I've had problems with not being too portable across older machinery. Which again, is because you're not double-quoting your parameter. The sentinel is not required if you double-quote your parameter (which you were already doing in your example). For example (with sentinel): if [ _$PTR == (sic) _ ] ; then Since you've already double-quoted the parameter, I'm letting you know that the sentinel is unnecessary. -- Devin All work as expected. It matters not the value of $foo. sh(1) in FreeBSD knows because of the double-quotes that it is not an operator. Furthermore... == is not the right operator. It's =. Portability would surely be compromised if you were using == (which doesn't work on FreeBSD; or many other OSes I gather from experience). Ooops, I did catch that and you're quite right. -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
On Mon, Jun 10, 2013 at 12:16 PM, Tim Daneliuk tun...@tundraware.com wrote: That wasn't really my point. I use sentinels because in the face of an empty string this: if [ $PTR = ] Actually evaluates to: if [ = ] Which throws an error. Right. Many scripts seem to assume that sh is bash, and that's certainly not the case here. if [ x$BLAH = x ]; then is the most reliable and portable way of determining if it's a string of zero length. - M ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of dte...@freebsd.org Sent: Monday, June 10, 2013 12:19 PM To: tun...@tundraware.com; freebsd-questions@freebsd.org Cc: dte...@freebsd.org Subject: RE: Bourne shell if syntax -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:17 PM To: dte...@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 02:10 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of Tim Daneliuk Sent: Monday, June 10, 2013 12:06 PM To: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax On 06/10/2013 01:59 PM, dte...@freebsd.org wrote: -Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of lcon...@go2france.com Sent: Monday, June 10, 2013 11:53 AM To: freebsd-questions@freebsd.org Subject: Bourne shell if syntax script fragment: PTR=`dig @some.dns +short +norec -x a.b.c.d` echo $PTR if [ $PTR ==] ; then if [ $PTR = ]; then or if [ -z $PTR ]; then or if [ $PTR ]; then but _NOT_ if [ $PTR == ]; then I work across a bunch of different OSs and shells of many vintages. As I recall, the -z argument has problems of portability on older/broken shells and/or is not available in all environments (I cannot recall which at the moment). So I achieve the same results by using a character sentinel that guarantees that the comparison always works: f [ _$PTR == _ ] ; then Character sentinels are not required. FreeBSD's sh(1) knows (because [ is a built-in) that when you quote a parameter, that it is not (even if the value begins with -) not an operator. That wasn't really my point. I use sentinels because in the face of an empty string this: if [ $PTR = ] Actually evaluates to: if [ = ] and hence why you shouldn't do that. Actually, there's another reason you should also avoid the above (unquoted parameter), and that's in the case of a multi-word value. For example: foo=abc 123 if [ $foo = ]; then Produces: sh: line 0: [: too many arguments -- Devin Instead do this: if [ $PTR = ] Which [potentially] evaluates to: if [ = ] Which throws an error. The character sentinel avoids this without having to use -z, which as I said, I've had problems with not being too portable across older machinery. Which again, is because you're not double-quoting your parameter. The sentinel is not required if you double-quote your parameter (which you were already doing in your example). For example (with sentinel): if [ _$PTR == (sic) _ ] ; then Since you've already double-quoted the parameter, I'm letting you know that the sentinel is unnecessary. -- Devin All work as expected. It matters not the value of $foo. sh(1) in FreeBSD knows because of the double-quotes that it is not an operator. Furthermore... == is not the right operator. It's =. Portability would surely be compromised if you were using == (which doesn't work on FreeBSD; or many other OSes I gather from experience). Ooops, I did catch that and you're quite right. -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- unsubscr...@freebsd.org _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list
Re: Bourne shell if syntax
On 06/10/2013 02:21 PM, dte...@freebsd.org wrote: ctually, there's another reason you should also avoid the above (unquoted parameter), and that's in the case of a multi-word value. For example: Yup, that's the compelling case for using quoting. -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Bourne shell if syntax
Michael Sierchio kudzu at tenebras.com writes: ... Right. Many scripts seem to assume that sh is bash, and that's certainly not the case here. if [ x$BLAH = x ]; then is the most reliable and portable way of determining if it's a string of zero length. Actually this trick is not needed any more (it has not been required for long time because the problem was fixed). http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-August/004275.html jb ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: buildworld selectively?
On Sun, Jun 9, 2013 at 4:27 PM, Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org wrote: Walter Hurry walterhu...@gmail.com writes: Ah, src.conf. That's what I missed!. Thank you so much Gary, and sorry if it was a silly question. Bear in mind that you're only going to be able to shave a small fraction off the build time. by excluding parts of the build. The 'games' section in particular has almost nothing in it. You can save great deal of build time if you don't need much. Between limiting what is built for world and kernel, most builds could be cut to a small fraction of what default is. For example, WITHOUT_CLANG alone save a lot of time. However to get a complete targeted build takes a good deal of effort. Usually only makes sense for mass deployments IME. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Your Ticket Order Confirmation
Thank you for purchasing tickets on Ticketmaster.Your order number for this purchase is 18-00609/AUS.Complete order detail is attached to this e-mail.You will receive your tickets via: International Express-Ticketmaster will mail these within 2 business days of the booking.Tickets usually arrive within 10 working days of posting.Total Charge: AU $198.50Thank you for adding Event Ticket Insurance to your order. You will be billed AU $13.00 (AU $6.50 per ticket)separately.Please note: for any ticket-related issues, please continue to contact Ticketmaster Customer Service. Thanks again for using Ticketmaster.Return to Ticketmaster home.You can always check your order and manage your preferences in My Ticketmaster. __ The personal information collected by Ticketmaster is used to ensure that the tickets or goods you purchased are delivered to you and that the you are advised of any possible changes/cancellations that may occur in relation to the event you booked. Ticketmaster collect personal financial information to confirm the identity of users and bill customers for products and services. Ticketmaster will not share financial or unique identifier information with third parties without your prior consent. When you make a purchase through the Ticketmaster system your consent is required to provide your financial or contact information to those third parties necessary to process your transactions with us, such as credit card companies and the companies that handle shipping on our behalf. Ticketmaster may also pass your contact details on to Venues and Presenters,who abide by the National Privacy Principles, to keep you informed of future events via direct marketing. You were asked at the time of booking if you would like to receive this information.You may also change this choice in the future by contacting us with this request, although it may also be necessary to contact any other organisations (Venues amp; Presenters) which have obtained your information to indicate your choice at this stage. Ticketmaster will not use or disclose this information in any way, other than that disclosed in this policy. This email confirms your ticket order, so print/save it for future reference. All purchases are subject to credit card approval and billing address verification. We make every effort to be accurate, but we cannot be responsible for changes, cancellations, or postponements announced after this email is sent.To update your information or to unsubscribe from Ticketmaster offers, click here.Note: This email was sent from an address that cannot accept incoming email Please do not reply to this message. If you have any questions please visit our Help Section.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Your Ticket Order Confirmation
Thank you for purchasing tickets on Ticketmaster.Your order number for this purchase is 06-89624/AUS.Complete order detail is attached to this e-mail.You will receive your tickets via: International Express-Ticketmaster will mail these within 2 business days of the booking.Tickets usually arrive within 10 working days of posting.Total Charge: AU $112.50Thank you for adding Event Ticket Insurance to your order. You will be billed AU $13.00 (AU $6.50 per ticket)separately.Please note: for any ticket-related issues, please continue to contact Ticketmaster Customer Service. Thanks again for using Ticketmaster.Return to Ticketmaster home.You can always check your order and manage your preferences in My Ticketmaster. __ The personal information collected by Ticketmaster is used to ensure that the tickets or goods you purchased are delivered to you and that the you are advised of any possible changes/cancellations that may occur in relation to the event you booked. Ticketmaster collect personal financial information to confirm the identity of users and bill customers for products and services. Ticketmaster will not share financial or unique identifier information with third parties without your prior consent. When you make a purchase through the Ticketmaster system your consent is required to provide your financial or contact information to those third parties necessary to process your transactions with us, such as credit card companies and the companies that handle shipping on our behalf. Ticketmaster may also pass your contact details on to Venues and Presenters,who abide by the National Privacy Principles, to keep you informed of future events via direct marketing. You were asked at the time of booking if you would like to receive this information.You may also change this choice in the future by contacting us with this request, although it may also be necessary to contact any other organisations (Venues amp; Presenters) which have obtained your information to indicate your choice at this stage. Ticketmaster will not use or disclose this information in any way, other than that disclosed in this policy. This email confirms your ticket order, so print/save it for future reference. All purchases are subject to credit card approval and billing address verification. We make every effort to be accurate, but we cannot be responsible for changes, cancellations, or postponements announced after this email is sent.To update your information or to unsubscribe from Ticketmaster offers, click here.Note: This email was sent from an address that cannot accept incoming email Please do not reply to this message. If you have any questions please visit our Help Section.___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: buildworld selectively?
Walter Hurry writes: Fair enough. Point taken, thanks. Nevertheless I see no reason to compile stuff I neither want nor need. While I endorse the principle ... it can be difficult for the casual user to know which parts can be removed without blowing up things they want. (Been there, had to change the underwear after the new kernel didn't boot. Booted old kernel, fixed things.) Wise words. The kernel and world builds/installs went fine, but soon afterwards I noticed a problem with the mail/dcc-dccd port (required, in my case, by SpamAssassin), which would not rebuild, complaining that the base sendmail was not found or too old. Since I use Postfix, I had set WITHOUT_SENDMAIL in /etc/src.conf. I shall remove it and rebuild. C'est la vie! My case was more spectacular: since there were no ISA slots I removed device ISA (or whatever it was). Turns out that dragged in a whole _truckload_ of essential infrastructure insert graphic of nuclear explosion Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Bourne shell if syntax
-Original Message- From: owner-freebsd-questi...@freebsd.org [mailto:owner-freebsd- questi...@freebsd.org] On Behalf Of jb Sent: Monday, June 10, 2013 12:53 PM To: freebsd-questions@freebsd.org Subject: Re: Bourne shell if syntax Michael Sierchio kudzu at tenebras.com writes: ... Right. Many scripts seem to assume that sh is bash, and that's certainly not the case here. if [ x$BLAH = x ]; then is the most reliable and portable way of determining if it's a string of zero length. Actually this trick is not needed any more (it has not been required for long time because the problem was fixed). http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012- August/004275.html The above link reinforces what I mentioned earlier as the divide. Differs based on whether [ is a built-in versus /usr/bin/[ -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Suddenly Seeing Clamav Errors After MailScanner Update
Hi Tim, Double check what user clamd is run as, and what permissions your mail spool have. Somewhere along the line your mail spool locked out clamd The lstat system call's man page says `execute (search) permission is required on all of the directories in path that lead to the file.` Also, don't just go chmoding -R 777! On Mon, Jun 10, 2013 at 12:03:51PM -0500, Tim Daneliuk wrote: I am working on a FBSD 9.1-STABLE mail machine that's been working fine. After upgrading to MailScanner 4.84.5_3, we are now suddenly seeing like this: Clamd::ERROR:: UNKNOWN CLAMD RETURN ./lstat() failed: Permission denied. ERROR :: /var/spool/MailScanner/incoming/68340 Any ideas what might cause this? I have fallen back to the previous MailScanner.conf file wherein the problem does NOT seem to happen. But, after diffing old and new config files I cannot see where anything relevant to this might have changed. Ideas anyone? -- --- Tim Daneliuk ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
