Re: bin/161927: bsdinstall(8): has no help describing what is happening
From-To: open-closed By: nwhitehorn When: Sun Oct 23 15:18:39 UTC 2011 Why: There is help throughout, in particular in the partition editor, which shows help in the bottom line of the screen. More verbose help (e.g. pressing F1 to open a help screen) will likely come later. http://www.freebsd.org/cgi/query-pr.cgi?pr=161927 If there is help throughout it sure is not in the 9.0 RC1 version. I object to the closing of this pr without any review by the current list. I can not understand how you can say there is help info provided in bsdinstall. The very first dialog box where users select (install) has no help. Every dialog box shown should have a help option. Saying it will come later is not the professional way software is released to the public. This is not the Freebsd standard. bsdinstall is the front door to FreeBSD and is the first thing installers see when trying to install it. Do you really want to show the public such a lack of pride in doing a complete job. In its current condition bsdinstall is not ready to be released. It gives the public the wrong impression (image) of what a great OS Freebsd is. Too many developers and other volunteers have invested tons of hours to have their united effort disrespected by a installer that is incomplete. This pr about adding help info is not the only outstanding pr on bsdinstall. ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
ead...@freebsd.org wrote: Synopsis: 9.0 burncd error caused by change to cd0 from acd0 State-Changed-From-To: open-analyzed State-Changed-By: eadler State-Changed-When: Mon Sep 26 23:24:00 UTC 2011 State-Changed-Why: requires only a release notes entry; use cdrecord instead of burncd http://www.freebsd.org/cgi/query-pr.cgi?pr=160979 Your solution is very un-professional. What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. You do not knowingly leave a non-working utility in the system, period, or not provide a included replacement for a popular utility as this one. The alternative is to fix burncd or backout the acd0 to cd0 change from 9.0 which may be the most desired solution because its obvious that no one researched the impact this change may have. This change may impact many ports that access cd/dvd drives for read and write access. burncd may be a very small worm in a large can of big worms. ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 17:59, Fbsd8 wrote: Your solution is very un-professional. Good thing we're all volunteers. :) What your solution purposes to do is do nothing. I think your judgment is flawed and a larger group of your peers need to review your judgment in this case. Ok, done. Eitan is right. burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. 2. burncd has only ever worked with a subset of the legacy ATA hardware. 3. ATA-CAM is on by default in FreeBSD 9 (which means that rather than acd0 as an ATA device you'll have cd0 as a SCSI device). 4. However, ATA-CAM is not mandatory, which means that leaving burncd in the base for those that want to continue using the legacy ATA interface is a perfectly reasonable course of action. 5. For those that wish to use the default ATA-CAM interface the cdrecord port provides a mature, full-featured solution. Even if it were possible to import it into the base, doing so would be a step in the wrong direction. You do not knowingly leave a non-working utility in the system, period, That makes sense, however see above. or not provide a included replacement for a popular utility as this one. The alternative already exists. The fact that it's not in the base has no relevance. I hope this clears up your confusion. If you have any further questions please direct them to freebsd-questions@FreeBSD.org only. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On 09/26/2011 18:43, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton do...@freebsd.org wrote: burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which is a SCSI device. The fact that it's emulated doesn't matter. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? Sure, as soon as someone volunteers to create that patch. No one is *trying* to annoy users, but things change around here because people are interested in changing them. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton do...@freebsd.org wrote:
I have used burncd on many releases of FreeBSD, on many machines
without problem. I can see the fact that burncd suddenly failing to
work on ATAPI hardware could annoy and confused end-users.
It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them burncd just doesn't work, when it used to.
Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
a more useful error message?
Sure, as soon as someone volunteers to create that patch. No one is
*trying* to annoy users, but things change around here because people
are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
flag = query for hw.ata.ata_cam_enabled sysctl;
if (flag == 1) {
printf(ERROR: ATA_CAM enabled, etc., etc.)
exit(1);
}
I only see these sysctls on a system with ATA_CAM enabled:
hw.ata.setmax: 0
hw.ata.wc: 1
hw.ata.atapi_dma: 1
hw.ata.ata_dma_check_80pin: 1
hw.ata.ata_dma: 1
dev.atapci.0.%desc: Intel ATA controller
dev.atapci.0.%driver: atapci
dev.atapci.0.%location: slot=3 function=2
dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x29b6 subvendor=0x1028
subdevice=0x0211 class=0x010185
dev.atapci.0.%parent: pci0
dev.ata.2.%desc: ATA channel 0
dev.ata.2.%driver: ata
dev.ata.2.%location: channel=0
dev.ata.2.%parent: atapci0
dev.ata.3.%desc: ATA channel 1
dev.ata.3.%driver: ata
dev.ata.3.%location: channel=1
dev.ata.3.%parent: atapci0
dev.ata.0.%driver: ata
dev.ata.0.%parent: isa0
dev.ata.1.%driver: ata
dev.ata.1.%parent: isa0
--
Craig Rodrigues
rodr...@crodrigues.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
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 6:28 PM, Doug Barton do...@freebsd.org wrote: burncd has been part of the system utilities included in the basic release since release 4.0 and cdrecord is a port. The professional solution is to remove burncd from the 9.0 system release and add the cdrecord command to the basic release as the replacement for burncd. Then add release notes entry of the change. I think you misunderstand the situation. So here are a few hopefully helpful facts: 1. The fact that something is in the base, or in the ports, has absolutely no bearing on whether one piece of software is fundamentally more useful or valuable than another. Hi, I have used burncd on many releases of FreeBSD, on many machines without problem. I can see the fact that burncd suddenly failing to work on ATAPI hardware could annoy and confused end-users. Fbsd8 has a valid point. Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out a more useful error message? ERROR: burncd does not work when ATAPI-CAM driver enabled. Install the sysutils/cdrtools port and use cdrecord instead. Please refer to http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD; While it is necessary to document all these things in release notes, documentation, etc., I don't always read every single last line of documentation or release notes when using a system, and I suspect many end-users are the same. :) I am a big fan of having the system issue diagnostic errors that give the user a clue how to remedy the problem, or pointers to relevant information. I even put Please in the error message to be nice. :) -- Craig Rodrigues rodr...@crodrigues.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
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote:
On Mon, Sep 26, 2011 at 6:58 PM, Doug Barton do...@freebsd.org wrote:
I have used burncd on many releases of FreeBSD, on many machines
without problem. I can see the fact that burncd suddenly failing to
work on ATAPI hardware could annoy and confused end-users.
It doesn't fail to work on ATAPI hardware. It fails to work on cd0 which
is a SCSI device. The fact that it's emulated doesn't matter.
True, but the subtlety of that distinction will be lost on a lot of end-users
not familiar with the implementation of the FreeBSD storage implementation.
To them burncd just doesn't work, when it used to.
Can we modify burncd to somehow detect if ATAPI-CAM is enabled, and print out
a more useful error message?
Sure, as soon as someone volunteers to create that patch. No one is
*trying* to annoy users, but things change around here because people
are interested in changing them.
I am not familiar enough with the ATA_CAM work. Is there a a sysctl or ioctl
that can be queried from userspace to detect if ATA_CAM is configured
in the kernel?
I would suggest something like:
...
Please fix it and move on.
Thanks,
-Garrett
$ usr.sbin/burncd/burncd -f /dev/cd0 blank
burncd: device provided not an acd(4) device: /dev/cd0.
Please verify that your kernel is built with acd(4) and the beforementioned
device is supported by acd(4).Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c(revision 225704)
+++ usr.sbin/burncd/burncd.c(working copy)
@@ -159,8 +159,16 @@
if ((fd = open(dev, O_RDWR, 0)) 0)
err(EX_NOINPUT, open(%s), dev);
- if (ioctl(fd, CDRIOCGETBLOCKSIZE, saved_block_size) 0)
- err(EX_IOERR, ioctl(CDRIOCGETBLOCKSIZE));
+ if (ioctl(fd, CDRIOCGETBLOCKSIZE, saved_block_size) 0) {
+ if (errno == ENOTTY)
+ errx(EX_IOERR,
+ device provided not an acd(4) device: %s.\n\n
+ Please verify that your kernel is built with
+ acd(4) and the beforementioned device is
+ supported by acd(4)., dev);
+ else
+ err(EX_IOERR, ioctl(CDRIOCGETBLOCKSIZE));
+ }
if (ioctl(fd, CDRIOCWRITESPEED, speed) 0)
err(EX_IOERR, ioctl(CDRIOCWRITESPEED));
___
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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper yaneg...@gmail.com wrote: ... Please fix it and move on. Thanks, -Garrett $ usr.sbin/burncd/burncd -f /dev/cd0 blank burncd: device provided not an acd(4) device: /dev/cd0. Please verify that your kernel is built with acd(4) and the beforementioned device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. (3) User has a system with USB CD-ROM only. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM (5) User has a system with SCSI CD-ROM only I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. -- Craig Rodrigues rodr...@crodrigues.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
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, 26 Sep 2011, Craig Rodrigues wrote: On Mon, Sep 26, 2011 at 8:30 PM, Garrett Cooper yaneg...@gmail.com wrote: ... Please fix it and move on. Thanks, -Garrett $ usr.sbin/burncd/burncd -f /dev/cd0 blank burncd: device provided not an acd(4) device: /dev/cd0. Please verify that your kernel is built with acd(4) and the beforementioned device is supported by acd(4). Hi, That patch is an improvement over the existing behavior. However, we may want to go a bit farther. Here are some possible scenarios: (1) User has a system with ATAPI CD-ROM only. Covered. (2) User has a system with ATAPI CD-ROM *and* USB CD-ROM. First case covered. Second case requires cdrecord anyhow, so don't care. (3) User has a system with USB CD-ROM only. Second case requires cdrecord anyhow, so don't care. (4) User has a system with ATAPI CD-ROM and SCSI CD-ROM Same as (2). (5) User has a system with SCSI CD-ROM only Same as (3). I would guess that (1) is the most common scenario, and end-users will definitely encounter it and complain. In the case of (1), it would be nice if we could fail if we try to burn to /dev/cd0, as per your patch, but still check to see if ATA_CAM is enabled in the kernel, and print out a message with pointers for using cdrtools. With your patch, a user will see a message about acd(4), and try to get it to compile/kldload/whatever acd(4) on their system, and then not get it to work because ATA_CAM is enabled. Adding notes to the burncd man page that burncd will not work on ATAPI devices if ATA_CAM is enabled would be good to do also. If the long term plan is to get rid of the old ATA subsystem, and completely move to ATA_CAM, then we should put a deprecation warning in the burncd man page as well, to give users a further heads-up. Noting something in the documentation is fine. The point is that there's a lot of wasted electrons being tossed about about a fairly trivial issue: most of the apps that burn/use CDs were converted over to some logic long ago that matches cdrecord. The only apps that haven't really been (atacontrol, burncd) were abandoned because the developer isn't an active maintainer. Thanks, -Garrett___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
.. and if someone would like to contribute patches to burncd to update it, I think there'd be at least one committer here who would be happy to help you get your changes into the tree. :-) Adrian ___ 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: bin/115406: [patch] gpt(8) GPT MBR hangs award BIOS on boot
Dan Naumov wrote: What exactly is gart and where do I find it's manpage, http://www.freebsd.org/cgi/man.cgi comes up with nothing? Also, does this mean that GPT is _NOT_ in fact fixed regarding this bug? That's gpart(8). With a 'p'. gpart has had significant amounts of work put into it for 8.0 release, and a lot of people are using it for eg. ZFS-root based systems, so it will probably work for you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: /bin/sh does not read profile
Hi Frank, Am Donnerstag, 05. Mär 2009, 04:15:05 + schrieb Frank Shute: On Wed, Mar 04, 2009 at 04:08:03PM +0100, Bertram Scharpf wrote: from man sh: Invocation [...] the shell inspects argument 0, and if it begins with a dash (`-'), the shell is also consid- ered a login shell. [...] A login shell first reads commands from the files /etc/profile and then .profile in a user's home directory, if they exist. [...] I use Slim (X login manager) which calls exec /bin/sh - ~/.xinitrc I've never before seen the syntax you've used and I think it comes from a misunderstanding of the manpage for sh and/or it's a bashism or a typo. It's the original FreeBSD port. E.g: /bin/sh -c somecommand (login shell - arg 0 starts with a dash) Sorry, this doesn't call /etc/profile either. $ uname -v FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de ___ 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: /bin/sh does not read profile
On Thu, Mar 05, 2009 at 02:23:52PM +0100, Bertram Scharpf wrote: Hi Frank, Hi Bertram, Am Donnerstag, 05. Mär 2009, 04:15:05 + schrieb Frank Shute: On Wed, Mar 04, 2009 at 04:08:03PM +0100, Bertram Scharpf wrote: from man sh: Invocation [...] the shell inspects argument 0, and if it begins with a dash (`-'), the shell is also consid- ered a login shell. [...] A login shell first reads commands from the files /etc/profile and then .profile in a user's home directory, if they exist. [...] I use Slim (X login manager) which calls exec /bin/sh - ~/.xinitrc I've never before seen the syntax you've used and I think it comes from a misunderstanding of the manpage for sh and/or it's a bashism or a typo. It's the original FreeBSD port. I suggest you take up your problem with the maintainer. (Mentioned at top of /usr/ports/x11/slim/Makefile). It should just work if that's the case. E.g: /bin/sh -c somecommand (login shell - arg 0 starts with a dash) Sorry, this doesn't call /etc/profile either. You're right. This is what my investigations reveal: $ /bin/sh date date: Can't open date: No such file or directory Not reading /etc/profile or ~/.profile $ /bin/sh -c date Thu Mar 5 16:33:17 GMT 2009 Reading ~/.profile but not /etc/profile I'm afraid I'm not a shell guru so I don't understand that particular weirdness. I think we need a shell wizard to explain it to us - these shells and sub-shells etc. are notoriously weird in my experience and half the time I just sacrifice goats to make it work. It could be that the manpage is wrong and the shell is just meant to read ~/.profile (or I'm reading it wrong). If nobody replies on this list, I suggest you post with your problem to hackers@ $ uname -v FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC $ uname -v FreeBSD 7.1-RELEASE-p2 #0: Wed Jan 28 21:45:37 GMT 2009 r...@orange.esperance-linux.co.uk:/usr/obj/usr/src/sys/ORANGE_MP2 BTW, my user shell is ksh. Bertram Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ 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: /bin/sh does not read profile
Good evening Betram et al. I've read the discussion thread as far as it went and would like to share my own solution to a similar problem, mapped onto the sh topic. Maybe it works. A little background: First of all, because my standard dialog shell is the system's C shell, the files important are /etc/cshrc with the settings, such as setenv, alias and path, furthermore /etc/csh.login to be executed after login, and /etc/csh.logout, executed after logout. Local to the user exist ~/.cshrc, ~/.login and ~/.logout which are used if present. In order to make X work properly with these settings, I have a kind of two stages mechanism which consists of the files ~/.xinitrc and ~/.xsession. The first one is used by X (xdm) to determine what to do after successful user login, e. g. start some programs and then exec the window manager / desktop environment. Note that both files are chmodded executable: % ll .xsession .xinitrc -rwxr-xr-x 1 poly pgm 807 Mar 3 02:46 .xinitrc* -rwxr-xr-x 1 poly pgm 43 Apr 27 2006 .xsession* The ~/.xsession doesn't do anything besides first incorporate settings from ~/.cshrc and then execute ~/.xinitrc. #!/bin/csh source ~/.cshrc exec ~/.xinitrc It is shebanged with the shell I want to use, which is the C shell. If ~/.xsession is called, it's last action is to execute ~/.xinitrc. If ~/.xsession is NOT called, ~/.xinitrc will be executed anyway. It does the following: #!/bin/sh [ -f ~/.xmodmaprc ] xmodmap ~/.xmodmaprc xrandr --size 1400x1050 xrandr --fb 1400x1050 xsetroot -solid rgb:3b/4c/7a # ... your initializations 'n stuff here ... exec wmaker Note that this script is shebanged for sh again. Any X terminals started now (with csh inside) have the settings from ~/.cshrc. Mapped onto the initial sh problem, I'd suggest to create the two files mentioned as follows: ~/.xsession: #!/bin/sh [ -f ~/.shrc ] . ~/.shrc [ -f ~/.profile ] . ~/.profile exec ~/.xinitrc ~/.xinitrc: #!/bin/sh [ -f ~/.shrc ] . ~/.shrc [ -f ~/.profile ] . ~/.profile my_init_stuff_1 my_init_stuff_2 my_init_stuff_3 exec my_wm_startup Now any instance of sh started should be aware of the settings. Finally, please note that I'm not a guru for sh (or bash) because I do use sh only for scripting, and bash never. :-) -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: /bin/sh does not read profile
On Wed, Mar 4, 2009 at 4:08 PM, Bertram Scharpf li...@bertram-scharpf.de wrote: Hi, from man sh: Invocation [...] When first starting, the shell inspects argument 0, and if it begins with a dash (`-'), the shell is also consid- ered a login shell. This is normally done automatically by the system when the user first logs in. A login shell first reads commands from the files /etc/profile and then .profile in a user's home directory, if they exist. [...] I use Slim (X login manager) which calls exec /bin/sh - ~/.xinitrc I first wondered why none of my commands in /etc/profile and ~/.profile got executed. Finally, I modified /usr/src/bin/sh/main.c to trace what files are read, recompiled the sh command and: the only file that is executed is ~/.shrc. I just cannot believe that FreeBSD has such a severe bug. What is going wrong here? Put the following in a file called .Xresources : XTerm*loginShell: true =Adriaan= ___ 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: /bin/sh does not read profile
I first wondered why none of my commands in /etc/profile and ~/.profile got executed. Finally, I modified /usr/src/bin/sh/main.c to trace what files are read, recompiled the sh command and: the only file that is executed is ~/.shrc. I just cannot believe that FreeBSD has such a severe bug. What is going wrong here? I have a similar problem, but with bash. I have both my personal account and root set to use bash instead of sh and when I login the .bashrc file is not read. My system does not have an X environment, it's plain old BSD. How can I get it to load .bashrc when I login? I'm using a 7.0 binary release. ___ 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: /bin/sh does not read profile
On Thu, 5 Mar 2009 18:11:18 -0800 (PST), Peter Steele pste...@maxiscale.com wrote: I have a similar problem, but with bash. I have both my personal account and root set to use bash instead of sh and when I login the .bashrc file is not read. My system does not have an X environment, it's plain old BSD. How can I get it to load .bashrc when I login? I'm using a 7.0 binary release. I read from the manpage bash-3.2.25 according to the FILES section: /etc/profile The systemwide initialization file, executed for login shells ~/.bash_profile The personal initialization file, executed for login shells ~/.bashrc The individual per-interactive-shell startup file When the shell is the login shell (prefixed with - in the process list), it seems that it needs to read ~/.bash_profile (and not the ~/.bashrc file). So you could put . ~/.bashrc into ~/.bash_profile to get a workaround. -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ 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: /bin/sh does not read profile
On Thu, Mar 05, 2009 at 06:11:18PM -0800, Peter Steele wrote: I first wondered why none of my commands in /etc/profile and ~/.profile got executed. Finally, I modified /usr/src/bin/sh/main.c to trace what files are read, recompiled the sh command and: the only file that is executed is ~/.shrc. I just cannot believe that FreeBSD has such a severe bug. What is going wrong here? I have a similar problem, but with bash. I have both my personal account and root set to use bash instead of sh and when I login the .bashrc file is not read. My system does not have an X environment, it's plain old BSD. How can I get it to load .bashrc when I login? I'm using a 7.0 binary release. You should be able to put: source $HOME/.bashrc in ~/.bash_profile That's if $HOME is set. Otherwise use the full path. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ 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: /bin/sh does not read profile
On Wed, Mar 04, 2009 at 04:08:03PM +0100, Bertram Scharpf wrote: Hi, from man sh: Invocation [...] When first starting, the shell inspects argument 0, and if it begins with a dash (`-'), the shell is also consid- ered a login shell. This is normally done automatically by the system when the user first logs in. A login shell first reads commands from the files /etc/profile and then .profile in a user's home directory, if they exist. [...] I use Slim (X login manager) which calls exec /bin/sh - ~/.xinitrc Usually ~/.xinitrc is parsed by the X server when it starts (startx is just a Bourne shell script) and you exec the last command (the window manager) in your ~/.xinitrc I've never before seen the syntax you've used and I think it comes from a misunderstanding of the manpage for sh and/or it's a bashism or a typo. E.g: /bin/sh -c somecommand (login shell - arg 0 starts with a dash) /bin/sh somecommand(not a login shell) I first wondered why none of my commands in /etc/profile and ~/.profile got executed. Finally, I modified /usr/src/bin/sh/main.c to trace what files are read, recompiled the sh command and: the only file that is executed is ~/.shrc. I just cannot believe that FreeBSD has such a severe bug. What is going wrong here? Thanks in advance, Bertram Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ 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: /bin/csh script in GELI partition crashes 6.3-STABLE
On Wed, 13 Feb 2008 08:58:01 +0100 Roland Smith [EMAIL PROTECTED] wrote: On Wed, Feb 13, 2008 at 12:59:41AM -0600, Scott Bennett wrote: % cat show #! /bin/csh set delay=3D3D2 set pixlist=3D3D(09 08 07 05 04 03 02 01) foreach i ($pixlist) (nice xv $i.jpg ) sleep $delay end =3D20 The delay is simply to ensure the windows get opened in the sequence t= hat I want them opened. The photos are in the same directory, and I run i= t by typing ./show in the directory. If I type, for example, xv 01.jpg= , =3D it works fine in either the old location or in the GELI partition. If I = type ./show in the copy of the directory that is in the GELI partition, F= ree=3D BSD reboots immediately.=3D20 I've run your script on a batch of photos on a GELI encrypted partition without problems. This is on FreeBSD 7.0-PRERELEASE amd64 I would look at the X server. Since it runs as root and has access to /dev/mem and /dev/io an X bug could potentially screw things up quite ni= cel=3D y. I'm running xorg-server-1.4_4,1. =20 I'm still running xorg-server-6.9.0_5, I believe. Haven't yet felt = like wading through the swamp of troubles that seems to await those who upgrade to 7.x, but will probably have to suffer through it soon. The base system upgrade was painless as usual for me. To prevent problems with ports, I had portmaster make a list of 'leaf' ports. Then I deleted all ports, installed the new base system and re-installed the leaf ports, which took care of the dependancies. Other than that it took a long time I didn't have problems with the upgrade. Glad it went easily for you. Maybe I'll get lucky, too, but the ports subsystem has burned me so often that I'll believe the upgrade is easy when I see it happen that way. If you have it installed, try display(1) from the ImageMagick suite instead of xv. See if it makes any difference. =20 There's a thought. However, I think first I'll try setting the GELI sector size to 4 KB to see whether that evades the bug. That makes sense. I've never used anything but the default settings for new= fs. I presume you've checked for the obvious things such as out of memory or filesystem full? =20 What do you mean out of memory? =20 Physical memory completely used and swap almost full.=20 No, that has never even come close to happening on my system. In these reboot cases, there were anywhere from 300 MB to 700 MB free, according to top, at the times of the reboots. Also, I have a swap partition of 5 GB. Usually none of it is used. Occasionally, there's enough going on to use a smidgen of it (like right now: 60 KB used). I think maybe once or twice since I first installed FreeBSD 5.2.1 years ago I've seen the swap usage exceed 1 MB. And I only had the file system loaded to about 45% after minfree. Maybe I should try GBDE instead of GELI. I chose GELI for the=3D= 20 partition in question mainly because I was already using it for the sw= ap partition, but maybe it's still a little too green to be reliable yet. =3D20 I've used it on my /home for years without trouble. =3D46rom what I've read, GELI is supposed to be more secure. Well, if I can get it to work and not cause instant reboots, I'll st= ick with it. Otherwise I'll have to play around with what works. The only trouble I ever had with GELI was to try and use encrypted USB mass storage devices. But those were apparently caused by a buggy USB-ATA chip. And there seems to be a workaround in the driver on 7.x because I haven't seen the problem since the upgrade. In this case, the GELI partition is on an external (USB) drive. I've never had any trouble at all with the drive or its cable, so that's probably not the problem. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, 12 Feb 2008 16:01:26 +0100 Roland Smith [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 08:02:49AM -0600, Scott Bennett wrote: I just set up a GELI partition for the first time a while ago (not counting the swap partition). After initializing the GELI device file, filling it from /dev/random, running newfs, and copying over a couple of directory trees from another file system, I tried running a C-shell script in one of the bottom-level directories. The script works fine in its original location, but after cd'ing to the new location and running it, the system immediately reboots. Because this leaves most/all of the file systems marked dirty, fsck has to run on startup. (I ran fsck by hand on the GELI partition.) It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts?=20 My /home is a GELI encrypted partition. I've never had problems running scripts from it, although my scripts are usually sh, not csh.=20 What does the script do? Are you running it as root? The script displays a bunch of pictures as separate xv(1) windows. No, I was running it under my own userid. It is quite simple: % cat show #! /bin/csh set delay=2 set pixlist=(09 08 07 05 04 03 02 01) foreach i ($pixlist) (nice xv $i.jpg ) sleep $delay end The delay is simply to ensure the windows get opened in the sequence that I want them opened. The photos are in the same directory, and I run it by typing ./show in the directory. If I type, for example, xv 01.jpg, it works fine in either the old location or in the GELI partition. If I type ./show in the copy of the directory that is in the GELI partition, FreeBSD reboots immediately. When it first happened, I thought maybe the machine had had some other problem, perhaps thermal, although I thought I'd dealt with its thermal problems. After it restarted, I thought nothing of it and typed ./show in the directory in the GELI partition again. It rebooted on the spot. I was shocked, to say the least. I may do a little more experimenting the next time I decide to shut down my tor server, but I doubt I will before then because I hate to crash the system with a server running. Maybe I should try GBDE instead of GELI. I chose GELI for the partition in question mainly because I was already using it for the swap partition, but maybe it's still a little too green to be reliable yet. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, 12 Feb 2008 16:06:45 +0100 [EMAIL PROTECTED]@mgEDV.net [EMAIL PROTECTED] wrote: Subject: /bin/csh script in GELI partition crashes 6.3-STABLE things i ran into with GELI/UFS2+S: - geli partition sector size larger than 4KB caused panics on one of our boxes Ah. Okay. I had set it to 8 KB for better performance. I'll try it again with it set to 4 KB. - fs sector size any than 512 sometimes caused hangs/watchdog reboots try setting up a kernel with debug-flags and integrated debugger (see ddb(4)) to catch a panic and get a backtrace if there's any. Well, that's a hardware feature I can't change. AFAIK, it's stuck at 512 bytes/sector on the drive in question. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, Feb 12, 2008 at 03:46:56PM -0600, Scott Bennett wrote: On Tue, 12 Feb 2008 16:01:26 +0100 Roland Smith [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 08:02:49AM -0600, Scott Bennett wrote: I just set up a GELI partition for the first time a while ago (not counting the swap partition). After initializing the GELI device file, filling it from /dev/random, running newfs, and copying over a couple of directory trees from another file system, I tried running a C-shell script in one of the bottom-level directories. The script works fine in its original location, but after cd'ing to the new location and running it, the system immediately reboots. Because this leaves most/all of the file systems marked dirty, fsck has to run on startup. (I ran fsck by hand on the GELI partition.) It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts?=20 My /home is a GELI encrypted partition. I've never had problems running scripts from it, although my scripts are usually sh, not csh. What does the script do? Are you running it as root? The script displays a bunch of pictures as separate xv(1) windows. No, I was running it under my own userid. It is quite simple: % cat show #! /bin/csh set delay=2 set pixlist=(09 08 07 05 04 03 02 01) foreach i ($pixlist) (nice xv $i.jpg ) sleep $delay end The delay is simply to ensure the windows get opened in the sequence that I want them opened. The photos are in the same directory, and I run it by typing ./show in the directory. If I type, for example, xv 01.jpg, it works fine in either the old location or in the GELI partition. If I type ./show in the copy of the directory that is in the GELI partition, FreeBSD reboots immediately. I've run your script on a batch of photos on a GELI encrypted partition without problems. This is on FreeBSD 7.0-PRERELEASE amd64 I would look at the X server. Since it runs as root and has access to /dev/mem and /dev/io an X bug could potentially screw things up quite nicely. I'm running xorg-server-1.4_4,1. If you have it installed, try display(1) from the ImageMagick suite instead of xv. See if it makes any difference. I presume you've checked for the obvious things such as out of memory or filesystem full? Maybe I should try GBDE instead of GELI. I chose GELI for the partition in question mainly because I was already using it for the swap partition, but maybe it's still a little too green to be reliable yet. I've used it on my /home for years without trouble. From what I've read, GELI is supposed to be more secure. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpgbmoa4txAo.pgp Description: PGP signature
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, 12 Feb 2008 15:16:59 +0100 Ivan Voras [EMAIL PROTECTED] wrote: Scott Bennett wrote: It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts? (I do not know whether the problem is limited to /bin/csh scripts. After several crashes in just a few minutes, I decided I had had enough of that for one night.) If anyone has seen this happen before, please let me know. This is absolutely not a common problem, and it's unlikely that the shell script is the direct cause of the reboots. Are there any messages written on the console juse before the reboots? Are the reboots actually None. kernel panics? If so, you'll need to track down the messages and report them (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html), The kernel panics I've seen in the past all hung the system cold and required powering it down in order to reboot it. The current situation involves a pause of one or two seconds, followed by a black screen, then the Dell startup splash screen, and then the screen displayed by my boot manager, offering a choice of Windows XP or FreeBSD. It's all very fast. I'm not at all sure that a final sync(2) is even done. if not, it's maybe a hardware problem. Is there something unusual about your hardware? I don't think so. It's a Dell Inspiron XPS w/1 GB of memory, a Mobility Radeon 9800 card, and several devices attached to USB ports. The CPU is a 3.4 GHz P4 w/HT enabled in chipset, BIOS, and kernel. There is also a Soundblaster Audigy 2ZS PCMCIA card in the slot. There is no software support for 3D acceleration on the graphics card and no software support for the sound card. There is a builtin sound setup for which there does seem to be some limited software support. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
Subject: /bin/csh script in GELI partition crashes 6.3-STABLE things i ran into with GELI/UFS2+S: - geli partition sector size larger than 4KB caused panics on one of our boxes - fs sector size any than 512 sometimes caused hangs/watchdog reboots try setting up a kernel with debug-flags and integrated debugger (see ddb(4)) to catch a panic and get a backtrace if there's any. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, Feb 12, 2008 at 08:02:49AM -0600, Scott Bennett wrote: I just set up a GELI partition for the first time a while ago (not counting the swap partition). After initializing the GELI device file, filling it from /dev/random, running newfs, and copying over a couple of directory trees from another file system, I tried running a C-shell script in one of the bottom-level directories. The script works fine in its original location, but after cd'ing to the new location and running it, the system immediately reboots. Because this leaves most/all of the file systems marked dirty, fsck has to run on startup. (I ran fsck by hand on the GELI partition.) It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts? My /home is a GELI encrypted partition. I've never had problems running scripts from it, although my scripts are usually sh, not csh. What does the script do? Are you running it as root? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp70X3eh7u9W.pgp Description: PGP signature
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
Scott Bennett wrote: It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts? (I do not know whether the problem is limited to /bin/csh scripts. After several crashes in just a few minutes, I decided I had had enough of that for one night.) If anyone has seen this happen before, please let me know. This is absolutely not a common problem, and it's unlikely that the shell script is the direct cause of the reboots. Are there any messages written on the console juse before the reboots? Are the reboots actually kernel panics? If so, you'll need to track down the messages and report them (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html), if not, it's maybe a hardware problem. Is there something unusual about your hardware? signature.asc Description: OpenPGP digital signature
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Tue, 12 Feb 2008 23:51:41 +0100 Roland Smith [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 03:46:56PM -0600, Scott Bennett wrote: On Tue, 12 Feb 2008 16:01:26 +0100 Roland Smith [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 08:02:49AM -0600, Scott Bennett wrote: I just set up a GELI partition for the first time a while ago (not counting the swap partition). After initializing the GELI device file, filling it from /dev/random, running newfs, and copying over a couple = of directory trees from another file system, I tried running a C-shell sc= ript in one of the bottom-level directories. The script works fine in its original location, but after cd'ing to the new location and running it, the system immediately reboots. Because this leaves most/all of the f= ile systems marked dirty, fsck has to run on startup. (I ran fsck by hand= on the GELI partition.) It does it every time, so it is certainly repeatable. Is this a known problem? Or is there some feature of GELI-encrypted file systems that is expected to have problems running scripts?=3D20 My /home is a GELI encrypted partition. I've never had problems running scripts from it, although my scripts are usually sh, not csh. What does the script do? Are you running it as root? The script displays a bunch of pictures as separate xv(1) windows. = No, I was running it under my own userid. It is quite simple: =20 % cat show #! /bin/csh set delay=3D2 set pixlist=3D(09 08 07 05 04 03 02 01) foreach i ($pixlist) (nice xv $i.jpg ) sleep $delay end =20 The delay is simply to ensure the windows get opened in the sequence that I want them opened. The photos are in the same directory, and I run it by typing ./show in the directory. If I type, for example, xv 01.jpg, = it works fine in either the old location or in the GELI partition. If I type ./show in the copy of the directory that is in the GELI partition, Free= BSD reboots immediately.=20 I've run your script on a batch of photos on a GELI encrypted partition without problems. This is on FreeBSD 7.0-PRERELEASE amd64 I would look at the X server. Since it runs as root and has access to /dev/mem and /dev/io an X bug could potentially screw things up quite nicel= y. I'm running xorg-server-1.4_4,1. I'm still running xorg-server-6.9.0_5, I believe. Haven't yet felt like wading through the swamp of troubles that seems to await those who upgrade to 7.x, but will probably have to suffer through it soon. If you have it installed, try display(1) from the ImageMagick suite instead of xv. See if it makes any difference. There's a thought. However, I think first I'll try setting the GELI sector size to 4 KB to see whether that evades the bug. I presume you've checked for the obvious things such as out of memory or filesystem full? What do you mean out of memory? And I only had the file system loaded to about 45% after minfree. Maybe I should try GBDE instead of GELI. I chose GELI for the=20 partition in question mainly because I was already using it for the swap partition, but maybe it's still a little too green to be reliable yet. =20 I've used it on my /home for years without trouble. =46rom what I've read, GELI is supposed to be more secure. Well, if I can get it to work and not cause instant reboots, I'll stick with it. Otherwise I'll have to play around with what works. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/csh script in GELI partition crashes 6.3-STABLE
On Wed, Feb 13, 2008 at 12:59:41AM -0600, Scott Bennett wrote: % cat show #! /bin/csh set delay=3D2 set pixlist=3D(09 08 07 05 04 03 02 01) foreach i ($pixlist) (nice xv $i.jpg ) sleep $delay end =20 The delay is simply to ensure the windows get opened in the sequence that I want them opened. The photos are in the same directory, and I run it by typing ./show in the directory. If I type, for example, xv 01.jpg, = it works fine in either the old location or in the GELI partition. If I type ./show in the copy of the directory that is in the GELI partition, Free= BSD reboots immediately.=20 I've run your script on a batch of photos on a GELI encrypted partition without problems. This is on FreeBSD 7.0-PRERELEASE amd64 I would look at the X server. Since it runs as root and has access to /dev/mem and /dev/io an X bug could potentially screw things up quite nicel= y. I'm running xorg-server-1.4_4,1. I'm still running xorg-server-6.9.0_5, I believe. Haven't yet felt like wading through the swamp of troubles that seems to await those who upgrade to 7.x, but will probably have to suffer through it soon. The base system upgrade was painless as usual for me. To prevent problems with ports, I had portmaster make a list of 'leaf' ports. Then I deleted all ports, installed the new base system and re-installed the leaf ports, which took care of the dependancies. Other than that it took a long time I didn't have problems with the upgrade. If you have it installed, try display(1) from the ImageMagick suite instead of xv. See if it makes any difference. There's a thought. However, I think first I'll try setting the GELI sector size to 4 KB to see whether that evades the bug. That makes sense. I've never used anything but the default settings for newfs. I presume you've checked for the obvious things such as out of memory or filesystem full? What do you mean out of memory? Physical memory completely used and swap almost full. And I only had the file system loaded to about 45% after minfree. Maybe I should try GBDE instead of GELI. I chose GELI for the=20 partition in question mainly because I was already using it for the swap partition, but maybe it's still a little too green to be reliable yet. =20 I've used it on my /home for years without trouble. =46rom what I've read, GELI is supposed to be more secure. Well, if I can get it to work and not cause instant reboots, I'll stick with it. Otherwise I'll have to play around with what works. The only trouble I ever had with GELI was to try and use encrypted USB mass storage devices. But those were apparently caused by a buggy USB-ATA chip. And there seems to be a workaround in the driver on 7.x because I haven't seen the problem since the upgrade. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpHgUbhBZYfh.pgp Description: PGP signature
Re: /bin/sh Can one Easily Strip Path Name from $0?
On Wed, Nov 14, 2007 at 09:08:57AM -0600, Martin McCormick wrote:
I am ashamed to admit that I have been writing shell
scripts for about 15 years but this problem has me stumped. $0
is the shell variable which contains the script name or at least
what name is linked to the script. The string in $0 may or may
not contain a path, depending upon how the script was called. It
is easy to strip off the path if it is always there
#! /bin/sh
PROGNAME=`echo $0 |awk 'BEGIN{FS=/}{print $NF}'`
echo $PROGNAME
That beautifully isolates the script name but if you happen to
call the script without prepending a path name such as when the
script is in the execution path, you get an error because there
are no slashes in the string so awk gets confused.
Is there a better way to always end up with only the script name and
nothing else no matter whether the path was prepended or not?
The basename(1) command seems to do what you want.
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Can one Easily Strip Path Name from $0?
In response to Martin McCormick [EMAIL PROTECTED]:
I am ashamed to admit that I have been writing shell
scripts for about 15 years but this problem has me stumped. $0
is the shell variable which contains the script name or at least
what name is linked to the script. The string in $0 may or may
not contain a path, depending upon how the script was called. It
is easy to strip off the path if it is always there
#! /bin/sh
PROGNAME=`echo $0 |awk 'BEGIN{FS=/}{print $NF}'`
echo $PROGNAME
That beautifully isolates the script name but if you happen to
call the script without prepending a path name such as when the
script is in the execution path, you get an error because there
are no slashes in the string so awk gets confused.
Is there a better way to always end up with only the script name and
nothing else no matter whether the path was prepended or not?
basename $0
--
Bill Moran
http://www.potentialtech.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Can one Easily Strip Path Name from $0?
Martin McCormick wrote:
I am ashamed to admit that I have been writing shell
scripts for about 15 years but this problem has me stumped. $0
is the shell variable which contains the script name or at least
what name is linked to the script. The string in $0 may or may
not contain a path, depending upon how the script was called. It
is easy to strip off the path if it is always there
#! /bin/sh
PROGNAME=`echo $0 |awk 'BEGIN{FS=/}{print $NF}'`
echo $PROGNAME
That beautifully isolates the script name but if you happen to
call the script without prepending a path name such as when the
script is in the execution path, you get an error because there
are no slashes in the string so awk gets confused.
Is there a better way to always end up with only the script name and
nothing else no matter whether the path was prepended or not?
basename should do it.
Thank you.
Martin McCormick
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Can one Easily Strip Path Name from $0?
The basename utility does the trick. Thanks to all of you who answered. Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Can one Easily Strip Path Name from $0?
Martin McCormick [EMAIL PROTECTED] writes:
I am ashamed to admit that I have been writing shell
scripts for about 15 years but this problem has me stumped. $0
is the shell variable which contains the script name or at least
what name is linked to the script. The string in $0 may or may
not contain a path, depending upon how the script was called. It
is easy to strip off the path if it is always there
#! /bin/sh
PROGNAME=`echo $0 |awk 'BEGIN{FS=/}{print $NF}'`
echo $PROGNAME
As said by others, you can use `basename`. Apart from this, you can
fix your old habit by prepending a '/' before '$0', like this:
#! /bin/sh
PROGNAME=`echo /$0 |awk 'BEGIN{FS=/}{print $NF}'`
echo $PROGNAME
Last, you can also use variable expansions mechanisms by saying:
PROGNAME=${0##*/}
The main difference with `basename` way is that the latter do not call
a subprogram.
(If you are sure there is no space in your name, you can remove the
quotes, but are you sure?)
See `Parameter Expansion' in sh(1).
--
Best wishes,
Michaël
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
I wasn't able to reproduce what you explained...maybe I missed something? i just do the following: clear /bin/sh EDITOR=vi export EDITOR set -o $EDITOR echo 1 echo 2 echo 3 echo 4 ESC-. and this is the output: test# /bin/sh test# EDITOR=vi export EDITOR set -o $EDITOR echo 1 echo 2 echo 3 echo 4 test# test# test# echo 1 1 test# echo 2 2 test# echo 3 3 test# echo 4 4 test# test# test# echo 2 2 test# echo 3 3 test# echo 4 4 test# test# interestingly, echo 1 is not re-executed but the other commands are. dunno what's going on here, but i really find it somewhat dangerous as a default root shell for a unix system (of course, in vi mode) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
i just do the following: clear /bin/sh EDITOR=vi export EDITOR set -o $EDITOR echo 1 echo 2 echo 3 echo 4 ESC-. I tested the command sequence you gave and the result was as you explained. What caught my attention, however, was that all the commands were builtin. I tested with non-builtin commands (eg. /bin/echo instead of echo) and ESC-. did nothing. In fact unless the last command was a builtin, ESC-. just repeated the last _editing_ action. This is not a desired behaviour however IMO, to repeat the last command (if builtin) upon a ESC-. on an empty line. Please correct me if I'm wrong. Bahman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
i just do the following: clear /bin/sh EDITOR=vi export EDITOR set -o $EDITOR echo 1 echo 2 echo 3 echo 4 ESC-. I tested the command sequence you gave and the result was as you explained. What caught my attention, however, was that all the commands were builtin. I tested with non-builtin commands (eg. /bin/echo instead of echo) and ESC-. did nothing. In fact unless the last command was a builtin, ESC-. just repeated the last _editing_ action. This is not a desired behaviour however IMO, to repeat the last command (if builtin) upon a ESC-. on an empty line. Please correct me if I'm wrong. well, now i did this: /bin/sh EDITOR=vi export EDITOR set -o $EDITOR echo 1 foo echo 2 foo cat foo foo1 cat foo1 foo cat foo with this result: test# /bin/sh test# EDITOR=vi test# export EDITOR test# set -o $EDITOR test# echo 1 foo test# echo 2 foo test# cat foo foo1 test# cat foo1 foo test# cat foo 1 2 1 2 test# test# echo 2 foo test# cat foo foo1 test# cat foo1 foo test# cat foo 1 2 1 2 2 1 2 1 2 1 2 2 test# i took care that foo and foo1 did not exist prior to testing! but i'm still not sure whether i should file a PR or not. my assumption and expectance for ESC-. would be: (regardless whether the input line is empty or not) - ignore the key completely - execute the last executed command again (ignoring the content in the input buffer) still, it's risky, maybe the command should not get executed but pasted into the commandline like with ESC-- (minus). executing should also be fine - if it's just the last command and not the whole history. this is not a feature - for me it seems to be much more than senseless. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
As far as I know, ESC-. (in fact hitting '.' when in command mode) repeats your very last action whether it was an editing action or executing a command. yes, that's true for vi, but not for /bin/sh in vi-mode. at least on my 6.2-RELEASE. ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
I wasn't able to reproduce what you explained...maybe I missed something? Bahman On 8/28/07, [EMAIL PROTECTED]@mgedv.net [EMAIL PROTECTED] wrote: As far as I know, ESC-. (in fact hitting '.' when in command mode) repeats your very last action whether it was an editing action or executing a command. yes, that's true for vi, but not for /bin/sh in vi-mode. at least on my 6.2-RELEASE. ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh vi mode command line editing and the period
As far as I know, ESC-. (in fact hitting '.' when in command mode) repeats your very last action whether it was an editing action or executing a command. Bahman On 8/27/07, [EMAIL PROTECTED]@mgedv.net [EMAIL PROTECTED] wrote: hi folks, when someone uses set -o vi to put /bin/sh into vi-mode for command line editing, he for example could use the ESC-minus sequence for editing the last executed command. but there's another bug/feature: ESC-. (period). when i (of course by mistake) hit this feature, all commands in the history IMMEDIATELY get executed without even pressing enter. is this a bug or a feature and how can i avoid this to happen - even with being in vi mode and in /bin/sh. from my point of view, this is a really dangerous thing, because commands like rm -rf or kill could easily get executed when they shouldn't! the documentation for vi shows that . should be used to edit the whole history and not to parse and execute it! (allocated to cmdline editing). cu / regards ps: just reply to the list, i'm on it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
*heh* DONT remove that.its normal. On 8/26/07, Jim Stapleton [EMAIL PROTECTED] wrote: Sorry if you get this question a lot - a few searches didn't find results for me. I have a /bin/[ file in my system - I just want to make sure it's not a sign of someone having hacked my machine. Thanks, -Jim Stapleton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
If you look at /etc/rc, the shell script that boots your system, you'll notice [ being called quite often. For better understanding, look at `man 1 [`. On Aug 26, 2007, at 3:57 PM, Jim Stapleton wrote: Sorry if you get this question a lot - a few searches didn't find results for me. I have a /bin/[ file in my system - I just want to make sure it's not a sign of someone having hacked my machine. Thanks, -Jim Stapleton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
Jeff Mohler wrote: *heh* DONT remove that.its normal. On 8/26/07, Jim Stapleton [EMAIL PROTECTED] wrote: Sorry if you get this question a lot - a few searches didn't find results for me. I have a /bin/[ file in my system - I just want to make sure it's not a sign of someone having hacked my machine. Thanks, -Jim Stapleton '[' is an extension of the test(1) program, an essential part for evaluating shell-related logic. -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jim Stapleton wrote: Sorry if you get this question a lot - a few searches didn't find results for me. I have a /bin/[ file in my system - I just want to make sure it's not a sign of someone having hacked my machine. No -- that's perfectly alright. If you look closely you can see that it is in fact identical to /bin/test: % ls -lai test '[' 871508 -r-xr-xr-x 2 root wheel 7652 Aug 18 12:31 [* 871508 -r-xr-xr-x 2 root wheel 7652 Aug 18 12:31 test* It's used for testing various conditions in shell scripts -- like this for example: [ x$foo != x ] echo \$foo is set to $foo which could be written equivalently as: test x$foo != x echo 2\$foo is set to $foo The curious name is historic, based on some early shells where there was a built-in syntax using the '[' character. Having test or [ as an external program means that all the standard shell on FreeBSD can use exactly the same test syntax and theres only one copy of the code to keep maintained in the source tree. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0e2e8Mjk52CukIwRCElMAJ40jLDH5y/TKKUJ7uT5Mv84LdnZgQCdG5Iy 4Y3I0l4+Hv9WMZTvl1jri64= =xzZw -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
Thanks everyone for the help. I tried using man, but it didn't find anything. Glad to know my system isn't compromised. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/[
Jim Stapleton wrote:
Thanks everyone for the help. I tried using man, but it didn't find
anything. Glad to know my system isn't compromised.
When searching for many shell sensitive commands and characters ('['
included), single-quoting the query will help you find what you need to
find.
Cheers,
-Garrett
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/cat: Permission denied
From: Viktoras Veitas [EMAIL PROTECTED]
Hello.
I suddenly cannot run cat command as /bin/cat file appears to be without
execute permissions (all other files in /bin directory are with them) and I
get /bin/cat: Permission denied error.
I had a misfortune to chmod 555 /bin/cat, then my machine panicked (when
trying to run cat) and was not able to boot until I changed the /bin/cat
permissions back to read-only. Anyway the system running again but I cannot
install almost any port that uses cat in ./configure script.
I am running FreeBSD 5.4-RELEASE-p16 on Intel(R) Pentium(R) 4 CPU 3.00GHz
(2992.52-MHz 686-class CPU), with two 200GB SATA disks and RAID1 geom
mirror.
Output of dmesg is attached as file.
Question#1: How can I get rid of this problem and repair my cat file to be
able to install new ports again?
Question#2: Why did this happen? I mean everything worked fine for a year or
more until I decided to use hylafax on my machine and found that it cannot
do documet conversion.
Maybe some kind soul you trust will send you a copy of the 5.4 cat
command. I'd suspect you redirected something to /bin/cat by mistake.
{^_^} Joanne
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/cat: Permission denied
jdow wrote:
From: Viktoras Veitas [EMAIL PROTECTED]
Hello.
I suddenly cannot run cat command as /bin/cat file appears to be
without
execute permissions (all other files in /bin directory are with them)
and I
get /bin/cat: Permission denied error.
I had a misfortune to chmod 555 /bin/cat, then my machine panicked
(when
trying to run cat) and was not able to boot until I changed the
/bin/cat
permissions back to read-only. Anyway the system running again but I
cannot
install almost any port that uses cat in ./configure script.
I am running FreeBSD 5.4-RELEASE-p16 on Intel(R) Pentium(R) 4 CPU 3.00GHz
(2992.52-MHz 686-class CPU), with two 200GB SATA disks and RAID1 geom
mirror.
Output of dmesg is attached as file.
Question#1: How can I get rid of this problem and repair my cat file
to be
able to install new ports again?
Question#2: Why did this happen? I mean everything worked fine for a
year or
more until I decided to use hylafax on my machine and found that it
cannot
do documet conversion.
Maybe some kind soul you trust will send you a copy of the 5.4 cat
command. I'd suspect you redirected something to /bin/cat by mistake.
{^_^} Joanne
Cat for i386 5.4 release can also be gotten from
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.4-RELEASE/base/base.aa
just use tar to extract it.
HTH,
Micah
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: /bin/sh: wildcard expansion fails
Incidentally, it is operating as documented (pathname expansion isn't listed as performed on redirection targets), and explicitly allowed by the POSIX standard. but /bin/sh could accept *txt until there's more than one file matching after expansion. if that's the case, an error like *blabla: invalid argument could be raised. not that i see this as a real problem, it's just a convenience-thing ;-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh: wildcard expansion fails
[EMAIL PROTECTED]@mgEDV.net [EMAIL PROTECTED] writes: i know things like cat *lst|wc, but i don't want to type them. when i try to use wildcards with or in /bin/sh, it fails: my input (only one file with this name exists in the current dir): wc *lst Which is equivalent to wc *lst, so I'm not sure why you'd want to do that... /bin/sh's output: cannot open *lst: No such file or directory is there a way to configure /bin/sh for more/better expansion? No. Incidentally, it is operating as documented (pathname expansion isn't listed as performed on redirection targets), and explicitly allowed by the POSIX standard. btw, with csh it works fine ;-) And some other shells too, I'm sure. Feel free to fix this yourself; if it still meets the POSIX standards (i.e., still errors out if the expansion returns multiple files), the change would probably be accepted... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Madness
Dan Nelson wrote:
In the last episode (Feb 16), Tim Daneliuk said:
Here is a shell function that behaves quite strangely:
#!/bin/sh
#
# Execute A Command, Noting Start/Stop Time, Logging Output
# Args:
# $1 Command Name
# $2 Log Directory
# $3 Command String To Execute
#
runupd()
{
log=$2/$1.log
timestamp $log
touch $2/.$1-begin eval $3 21 $log touch $2/.$1-end
}
# End of 'runupd()'
So, you might do something like:
runupd freespace /var/log/ df -k
Now, for the weirdness. This function works fine in my script
so long as one of two conditions is met:
1) I run it interactively from the command line (bash)
OR
2) I run it from 'cron' AND $3 is *not* another script
If I try to run it from 'cron' and point $3 to a script, everything gets
run as planned, however, the ending timestamp (touch $2/.$1-end) never
runs. That is, the initial time stamp (.$1-begin) and the command itself
are executed, and output is properly written to the logfile,
but the final timestamp never happens.
Could your $3 command be returning a nonzero exit code? You probably
want something more like
touch $2/.$1-begin { eval $3 21 $log ; touch $2/.$1-end }
I am looking into this.
so your end timestamp always gets created whether or not $3 succeeds.
Also note that in your original script, you only backgrounded touch
$2/.$1-end, which is probably not what you wanted.
H - I have invoked the script that uses this function a variety
of ways and the command being evaled *is* being backgrounded in
every case with the syntax shown above ...
--
Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Madness
Dan Nelson wrote:
In the last episode (Feb 16), Tim Daneliuk said:
Here is a shell function that behaves quite strangely:
#!/bin/sh
#
# Execute A Command, Noting Start/Stop Time, Logging Output
# Args:
# $1 Command Name
# $2 Log Directory
# $3 Command String To Execute
#
runupd()
{
log=$2/$1.log
timestamp $log
touch $2/.$1-begin eval $3 21 $log touch $2/.$1-end
}
# End of 'runupd()'
So, you might do something like:
runupd freespace /var/log/ df -k
Now, for the weirdness. This function works fine in my script
so long as one of two conditions is met:
1) I run it interactively from the command line (bash)
OR
2) I run it from 'cron' AND $3 is *not* another script
If I try to run it from 'cron' and point $3 to a script, everything gets
run as planned, however, the ending timestamp (touch $2/.$1-end) never
runs. That is, the initial time stamp (.$1-begin) and the command itself
are executed, and output is properly written to the logfile,
but the final timestamp never happens.
Could your $3 command be returning a nonzero exit code? You probably
want something more like
touch $2/.$1-begin { eval $3 21 $log ; touch $2/.$1-end }
so your end timestamp always gets created whether or not $3 succeeds.
Also note that in your original script, you only backgrounded touch
$2/.$1-end, which is probably not what you wanted.
This seems not to work - I don't think 'sh' likes nested function braces -
recall that this command appears inside a shell function.
In any case, I think I have nailed the problem. It seems that the
external script being called made reference to 'chown' without explicitly
naming the program's path. Under 'cron' control, there is no path to
/usr/sbin by default so the script was exiting with a non-zero exit status
as several here suggested. Wipes large glob off egg off very red face.
Many thanks to all who took time to answer.
--
Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Madness
In the last episode (Feb 17), Tim Daneliuk said:
Dan Nelson wrote:
Could your $3 command be returning a nonzero exit code? You probably
want something more like
touch $2/.$1-begin { eval $3 21 $log ; touch $2/.$1-end }
so your end timestamp always gets created whether or not $3 succeeds.
Also note that in your original script, you only backgrounded touch
$2/.$1-end, which is probably not what you wanted.
This seems not to work - I don't think 'sh' likes nested function
braces - recall that this command appears inside a shell function.
Oops. Braces aren't bourne syntax, and in this case they're the wrong
choice anyway. parens (i.e. a subshell) are what's needed.
touch $2/.$1-begin ( eval $3 21 $log ; touch $2/.$1-end )
I actually tested this one :)
In any case, I think I have nailed the problem. It seems that the
external script being called made reference to 'chown' without explicitly
naming the program's path. Under 'cron' control, there is no path to
/usr/sbin by default so the script was exiting with a non-zero exit
status as several here suggested. Wipes large glob off egg off very
red face.
Many thanks to all who took time to answer.
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh Madness
In the last episode (Feb 16), Tim Daneliuk said:
Here is a shell function that behaves quite strangely:
#!/bin/sh
#
# Execute A Command, Noting Start/Stop Time, Logging Output
# Args:
# $1 Command Name
# $2 Log Directory
# $3 Command String To Execute
#
runupd()
{
log=$2/$1.log
timestamp $log
touch $2/.$1-begin eval $3 21 $log touch $2/.$1-end
}
# End of 'runupd()'
So, you might do something like:
runupd freespace /var/log/ df -k
Now, for the weirdness. This function works fine in my script
so long as one of two conditions is met:
1) I run it interactively from the command line (bash)
OR
2) I run it from 'cron' AND $3 is *not* another script
If I try to run it from 'cron' and point $3 to a script, everything gets
run as planned, however, the ending timestamp (touch $2/.$1-end) never
runs. That is, the initial time stamp (.$1-begin) and the command itself
are executed, and output is properly written to the logfile,
but the final timestamp never happens.
Could your $3 command be returning a nonzero exit code? You probably
want something more like
touch $2/.$1-begin { eval $3 21 $log ; touch $2/.$1-end }
so your end timestamp always gets created whether or not $3 succeeds.
Also note that in your original script, you only backgrounded touch
$2/.$1-end, which is probably not what you wanted.
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/sh, php mysql
George Dew wrote: After upgrading to BSD 4.11, I've been having all sorts of problems. Please help! - The shell no longer supports the up cursor key, which gives a history of commands that you type. Which shell you were using before upgrade ? And which one do u use now ? Just change it to one,that you used before upgrade. - Also, mod_php no longer supports mySQL. Does anyone know what's going on here? Did you recompile all the installed ports after upgrading to 4.11 ? If not,then do it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/rm: Argument list too long.
On Fri, 19 Nov 2004, Dennis Koegel wrote: find /foo/bar -type f -maxdepth 1 | xargs rm -n100 Although xargs is the most versatile solution for when having too many items listed, for just deleting find itself can do it.. find /foo/bar -n mask -delete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/rm: Argument list too long.
On Fri, Nov 19, 2004 at 09:58:40AM +0100, Mipam wrote: I tried to delete all files from a dir, however I got this message: /bin/rm: Argument list too long. You probably did rm *, and * expanded to too many files. One way is to simply remove the directory completely (rm -r /foo/bar), but this also removes all subdirectories. Other way would be to use find and xargs; in this example for only the files in one specific directory and no subdirectories (and no symlinks, that is): find /foo/bar -type f -maxdepth 1 | xargs rm -n100 ... where -n controls the number of arguments passed per one execution of rm. HTH, - D. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/rm: Argument list too long.
Mipam wrote: Hi, I tried to delete all files from a dir, however I got this message: /bin/rm: Argument list too long. So, no go. newfs is also no option, because the dir is not a seperate fs. Any hints exept for manual labour? Bye, Mipam. I gather it's rm * that's not working? If so, try a subset, e.g. rm a* or something else that's fairly common, and see if you can just rm * after that. -BB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/rm: Argument list too long.
On Fri, Nov 19, 2004 at 10:19:39AM +0100, Dennis Koegel typed: snip find /foo/bar -type f -maxdepth 1 | xargs rm -n100 or just ls | xargs rm ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: bin. packages compilation options
I mean the binaries distributed by freebsd community (available via FTP), not those I compile, do they have any optimization? -Original Message- From: Paul Everlund [mailto:[EMAIL PROTECTED] Sent: Friday, July 09, 2004 6:00 PM To: Kyryll Mirnenko Subject: Re: bin. packages compilation options Kyryll Mirnenko wrote: What flags (e.g. optimization, target arch.) are FreeBSD binaries (core packages) compiled with? Is there a standart? Take a look at /etc/defaults/make.conf. This file is preceded by /etc/make.conf, if it exists. Best regards, Paul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin. packages compilation options
Kyryll Mirnenko wrote: I mean the binaries distributed by freebsd community (available via FTP), not those I compile, do they have any optimization? Yes, the standard CFLAGS are something close to -O -pipe. There is work in progess to fix some coding problems within the base system and have -O2 supported in -CURRENT. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: .bin executable
On Wed, Jan 07, 2004 at 11:03:22AM +, gffds fsdff wrote: How would I go about executing hlds_l_1120_full.bin (STEAM) in order to extract it. I have also tried non-steam hlds_l_3110_full.bin with no success, however due to STEAM taking impact on modifications I must now use STEAM. From the commandline: sh hlds_l_1120_full.bin Alternatively you could make the file executable: chmod +x hlds_l_1120_full.bin and then run it: ./hlds_l_1120_full.bin although this depends on the shebang line (first line in the .bin file) being set correctly to reflect the interpreter to use to execute the file. IIRC that .bin file for hlds is just a shar archive (shell executable archive). -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ http://jez.hancock-family.com/ - personal weblog http://ipfwstats.sf.net/- ipfw peruser traffic logging ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: #!/bin/sh execve
the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. It also suffers from problems with arguments that are meant to include spaces, like: #!/bin/sh hello world foo bar Without a fully functional sh(1)-like parser, any solution that does magic with argv[] is incomplete :-( Apologies for a delayed response. This concerned how to load execve()'s argv[] array when parsing the 'shebang' line of a script, ie: whether to pass everything after '#!/interpeter' 1. as one string into execve()'s argv[] array, as some systems do, or 2. as individual arguments, as exist after #!/interpreter, separated by whitespace. Bug report 16383 showed the variance in the various UNIX's of how this is done. Orginal SysV specs say to load '1 argument' only after #!/interpreter, leaving it ambiguous as to whether the '1 argument' is the 1st whitespace separated argument, or whether it is everything after #!/interpreter as one string. Posix and SUSv3 don't say anything about how to load execve()'s argv[] array after #!/interpreter, and seem to leave it to whatever is the most intelligent way. I suggested it made more sense as FBSD 2.2.7 used to do it, where execve()'s argv[] array was loaded contiguously with whitespace separated elements, so one could use constructs such as #!/bin/sh /script-preprocessor options, and to allow #!/interpreter opt1 opt2 and #!/interpreter opt1 arg1 type constructs, things that intuitively work as one would expect on a command line, since there didn't appear to be any penalty for allowing this flexibility. A plausible argument was given in response: #!/bin/sh hello world foo bar I repond as follows: that's something only a Windoze user would think of doing! :) Unix users don't put whitespace in filenames, nor would they create options to programs that contain whitespace. Also, to load: 'hello world foo bar' as one string, breaks it's purpose anyway. it is a bizarre example that has little practical value, and can be easily compensated for by getting rid of whitespace in a filename, in the bizarre case where it may exist as such. Finally, to be slightly extreme with a tiny performance penalty, a beginning and ending quote in a string could be check for and respected by execve()'s code that fills argv[]. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
Oh boy! Deja-vu... On 2003-02-28 18:32, [EMAIL PROTECTED] wrote: This concerned how to load execve()'s argv[] array when parsing the 'shebang' line of a script, ie: whether to pass everything after '#!/interpeter' 1. as one string into execve()'s argv[] array, as some systems do, or 2. as individual arguments, as exist after #!/interpreter, separated by whitespace. I don't like 2 and I will definitely suggest that it's *not* implementd for various reasons. See below. Bug report 16383 showed the variance in the various UNIX's of how this is done. I'm not sure if this is the right bug report. The (closed now) ports/16383 PR is about a broken port, that has been fixed. Orginal SysV specs say to load '1 argument' only after #!/interpreter, leaving it ambiguous as to whether the '1 argument' is the 1st whitespace separated argument, or whether it is everything after #!/interpreter as one string. I don't mean to sound harsh here, but FreeBSD is BSD not SysV. We don't have to copy SysV 'bugs', and splitting blindly at whitespace is something I'll always consider a bug :( Posix and SUSv3 don't say anything about how to load execve()'s argv[] array after #!/interpreter, and seem to leave it to whatever is the most intelligent way. If they don't explicitly require a certain feature then it's not mandatory to implement it in any particular way. I suggested it made more sense as FBSD 2.2.7 used to do it, where execve()'s argv[] array was loaded contiguously with whitespace separated elements, so one could use constructs such as #!/bin/sh /script-preprocessor options, and to allow #!/interpreter opt1 opt2 and #!/interpreter opt1 arg1 type constructs, things that intuitively work as one would expect on a command line, since there didn't appear to be any penalty for allowing this flexibility. A plausible argument was given in response: #!/bin/sh hello world foo bar Thanks for 'plausible' :) I repond as follows: that's something only a Windoze user would think of doing! :) Unix users don't put whitespace in filenames, nor would they create options to programs that contain whitespace. The only characters that are not allowed to be part of a filename are the path separator and ASCII nul '\0'. I don't like and I won't ever accept limitations other than that. Doing special things for any other character is one of the technical reasons why I don't use DOS and/or Windows. Why do you think that we have to do this in a way that is obviously broken for filenames that are perfectly valid? Also, to load: 'hello world foo bar' as one string, breaks it's purpose anyway. It still is a valid filename, and I might choose to write a shell script called Find misfiled PRs.sh. How do you then propose that exec*() should handle filenames of that sort? it is a bizarre example that has little practical value, and can be easily compensated for by getting rid of whitespace in a filename, There are various reasons why splitting blindly on whitespace is a bug waiting in the background of programs to bite you in the future. For another known problem with this way of splitting parts of a command line look at http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/35678. A very annoying 'feature' of make(1)... Do we really have to copy it to the way exec*() works? Also, think about Samba shares. One doesn't always have control of what something includes in the name. If I mount over Samba a Windows filesystem that contains some of my shell scripts why does it seem good to you to force limitations on me about the way I name my files? FreeBSD used to have a motto along the lines of We provide the tools, and you make the policy. Implementing and mandating limitations of this sort is something that is far beyond the borders of tools and very deep within the heart of policy. I don't like this... at all :( in the bizarre case where it may exist as such. Finally, to be slightly extreme with a tiny performance penalty, a beginning and ending quote in a string could be check for and respected by execve()'s code that fills argv[]. I'd have to see the code and several sample scripts to comment on this. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: /bin/sh logout script
On Tue, Feb 25, 2003 at 12:19:45PM +0100, dick hoogendijk wrote: For bash I can use .bash_profile and .bash_logout to get things done at login/logout time. On my fbsd machine I use /bin/sh and I can't find how to execute things at logout time (login is set in .profile). I.e. I want to remove the ssh-agent pig at logout time and clear the screen) Does /bin/sh has a logout file ??? and if so, what's it called? Hmmm... I don't think that /bin/sh does have a logout script. However, you may still be able to use ssh-agent using the alternative syntax. You can tell ssh-agent to spawn another command, which is usually used for something like a window manager. Try putting a line like this at the end of your .profile: exec ssh-agent /bin/sh which should put you into your usual shell running as a child of the ssh-agent. Once in, check your environment: there should be SSH_AUTH_SOCK and SSH_AGENT_PID environment variables. The ssh-agent will run until you exit from the shell, and you can load keys into it as normal. Warning: make sure you have an alternate login you can use to fix your account if this all goes horribly wrong and stops you being able to log in at all. I haven't tested doing anything like this myself, so I really don't know if it will work properly or not. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: /bin/sh logout script
Hi, I saw something about this long time ago. The ideea was to use 'trap' i login script to install a handler, and so you will catch a signal (i don't remember what signal - INT, ??), and make a function in login script that executes the desired actions. Hope will help you -- __V__ Ciprian Badescu A L C A T E L Mobile Networks Division RD Center Phone: +40 56 303100 (ext. 5786) Fax: +40 56 295386 Email: [EMAIL PROTECTED] On Tue, 25 Feb 2003, Matthew Seaman wrote: Date: Tue, 25 Feb 2003 11:33:58 + From: Matthew Seaman [EMAIL PROTECTED] To: freebsd-questions [EMAIL PROTECTED] Subject: Re: /bin/sh logout script On Tue, Feb 25, 2003 at 12:19:45PM +0100, dick hoogendijk wrote: For bash I can use .bash_profile and .bash_logout to get things done at login/logout time. On my fbsd machine I use /bin/sh and I can't find how to execute things at logout time (login is set in .profile). I.e. I want to remove the ssh-agent pig at logout time and clear the screen) Does /bin/sh has a logout file ??? and if so, what's it called? Hmmm... I don't think that /bin/sh does have a logout script. However, you may still be able to use ssh-agent using the alternative syntax. You can tell ssh-agent to spawn another command, which is usually used for something like a window manager. Try putting a line like this at the end of your .profile: exec ssh-agent /bin/sh which should put you into your usual shell running as a child of the ssh-agent. Once in, check your environment: there should be SSH_AUTH_SOCK and SSH_AGENT_PID environment variables. The ssh-agent will run until you exit from the shell, and you can load keys into it as normal. Warning: make sure you have an alternate login you can use to fix your account if this all goes horribly wrong and stops you being able to log in at all. I haven't tested doing anything like this myself, so I really don't know if it will work properly or not. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
On 2003-02-08 21:58, [EMAIL PROTECTED] wrote: this does seem to be an ambiguous area. it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. This is something that can be bth good and bad though. As you have pointed out, if a limited sort of parsing is allowed, then it would most likely have to be sh(1)-like. This means that the mechanism that inteprets '#!' would have to know all the intricacies of the sh(1) parser to work correctly in all cases. Incomplete sh(1)-like parsers that would understand most of the sh(1) shell syntax would be exactly that... incomplete. Another bad thing about this is that you would then need a lot more memory to handle things like: #!/bin/sh -c \ 'my-magic-script.sh arg1 arg2 \ arg3 ...' \ `backquoted command` I'm not objecting to something like this. If you happen to roll patches for the kernel that can make it work, I'll probably try them too. But are the benefits of writing something like this worth the time required to write and test it? i don't know how it breaks anything to load execve's argv[] with everything after the shebang, followed by command line options/args. but it sure muddies the water if you don't. There is one portable way. It's easy to remember too: #!/bin/sh No spaces, no args. It works so far on all the systems I've tried. #!/bin/sh -xthis is obviously ok. #!/bin/sh set -x [...] #!/bin/sh -vx this is obviously ok too. Similarly. #!/bin/sh -cstringthis is currently not ok, but why shouldn't it be? #!/bin/sh exec string exit 1 #!/bin/sh -c string this is currently not ok, but why shouldn't it be? Similarly. #!/bin/sh scriptthis is obviously ok. #!/bin/sh . script #!/bin/sh -n script this is currently not ok, but why shouldn't it be? #!/bin/sh exec /bin/sh -n script #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? #!/bin/sh exec /bin/sh script 1 2 it seems that only a minority of execve() man pages / implementations are preventing the sane solution ... The only objection I have in making execve() behave as if the whole she-bang thing was a valid sh(1) command, is that I don't want sh(1) being imported into the kernel tree, period. Of course, what I want is irrelevant if someone comes up with a solution to the problem of having an sh(1)-like parser without having sh(1) in the kernel :-) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. This is something that can be bth good and bad though. As you have pointed out, if a limited sort of parsing is allowed, then it would most likely have to be sh(1)-like. This means that the mechanism that inteprets '#!' would have to know all the intricacies of the sh(1) parser to work correctly in all cases. Incomplete sh(1)-like parsers that would understand most of the sh(1) shell syntax would be exactly that... incomplete. the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. i thank you very much for explaining this to me. Another bad thing about this is that you would then need a lot more memory to handle things like: #!/bin/sh -c \ 'my-magic-script.sh arg1 arg2 \ arg3 ...' \ `backquoted command` I'm not objecting to something like this. If you happen to roll patches for the kernel that can make it work, I'll probably try them too. But are the benefits of writing something like this worth the time required to write and test it? i agree. my main problem, which doesn't exist with FBSD (thankfully), was, for example, scriptA --- #!/bin/sh ./scriptB 1 2 3 where scriptB runs (with options), then processes scriptA, then exec's scriptA with a modified command line. (it would've been a long chore to write scriptB in C code, and it would've been a kludge to run scriptB on the command line with scriptA as an argument - forcing one to always type 2 words to do one command). many OS's do not allow this since they load ./scriptB 1 2 3 into a single argv[] element, which, of course, the interpreter cannot run. which seemed very stupid to me. i saw problems and limitations, and no benefit to that solution. There is one portable way. It's easy to remember too: #!/bin/sh No spaces, no args. It works so far on all the systems I've tried. heh - yes - i agree. i was afraid someone would pick apart all this! i didn't really take the time to study the functionality of the sh(1) options. i only meant to show the unintuitive nature of the implimentations with regard to parsing. #!/bin/sh scriptthis is obviously ok. #!/bin/sh . script this won't work if script is going to do something before exec'ing the file itself. it will end up being infinitely recursive. and similarly for the following: #!/bin/sh -n script this is currently not ok but why shouldn't it be? #!/bin/sh exec /bin/sh -n script #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? #!/bin/sh exec /bin/sh script 1 2 The only objection I have in making execve() behave as if the whole she-bang thing was a valid sh(1) command, is that I don't want sh(1) being imported into the kernel tree, period. Of course, what I want is irrelevant if someone comes up with a solution to the problem of having an sh(1)-like parser without having sh(1) in the kernel :-) yes - i agree. i think freebsd hackers are the best. and have the best design/implementation philosophies. i am always humbled in their presence. - Giorgos thank you. Freebsd seems to be the only intelligent OS. 2.2.7, imho, seems to be correct. it may not follow, but sometimes intelligence has to lead ... I would be interested in anyone could tell me how/why any of the other solutions are more intelligent/practical. It is my personal observation the solutions of most vendors is due to SysV's limiting definition of execve(2). But I did note that Posix/SUSv3 definitions remove such arbitrary limitations (the single [arg]). #!/tmp/interp -a -b -c #d e Solaris 8: args: /tmp/interp -a/tmp/x2 Tru64 4.0: args: interp -a -b -c #d e /tmp/x2 *FreeBSD 2.2.7: args: /tmp/interp -a -b -c #d e /tmp/x2 FreeBSD 4.0: args: /tmp/interp -a -b -c /tmp/x2 Linux 2.4.12: args: /tmp/interp -a -b -c #d e /tmp/x2 Linux 2.2.19: args: interp -a -b -c #d e /tmp/x2 Irix 6.5: args: /tmp/interp -a -b -c #d e /tmp/x2 HPUX 11.00:args: /tmp/x2 -a -b -c #d e /tmp/x2 AIX 4.3: args: interp -a -b -c #d e /tmp/x2 Mac OX X: args: interp -a -b -c #d e /tmp/x2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
Please don't remove me from the Cc: list when you reply to posts that you want me to see. Otherwise, I might miss one of your replies and give you the false impression that I'm somehow ignoring your posts. On 2003-02-10 01:18, [EMAIL PROTECTED] wrote: Giorgos Keramidas wrote: [EMAIL PROTECTED] wrote: it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. This is something that can be bth good and bad though. As you have pointed out, if a limited sort of parsing is allowed, then it would most likely have to be sh(1)-like. This means that the mechanism that inteprets '#!' would have to know all the intricacies of the sh(1) parser to work correctly in all cases. Incomplete sh(1)-like parsers that would understand most of the sh(1) shell syntax would be exactly that... incomplete. the method used by FBSD 2.2.7 seems the most sane to me, where execve's argv[] is loaded by each whitespace seperated element after the shebang, then by command line options. 1. it is flexible. 2. it functions intuitively. 3. i don't think it breaks less flexible methods. It also suffers from problems with arguments that are meant to include spaces, like: #!/bin/sh hello world foo bar Without a fully functional sh(1)-like parser, any solution that does magic with argv[] is incomplete :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
minor correction/addition to previous post: instead of infinitely recursive, i should've said that it would break things if script re-exec's the same file with a different interpreter. -- #!/bin/sh . script this won't work if script is going to do something before exec'ing the file itself. it will end up being infinitely recursive. and similarly for the following: #!/bin/sh -n script this is currently not ok but why shouldn't it be? #!/bin/sh exec /bin/sh -n script #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? #!/bin/sh exec /bin/sh script 1 2 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
On Sat, 8 Feb 2003 [EMAIL PROTECTED] wrote: say i have 2 scripts, scriptA and scriptB. scriptA --- #!/bin/sh ./scriptB 1 2 3 scriptB --- #!/bin/sh echo 0:$0 echo 1:$1 echo 2:$2 echo 3:$3 -- $ ./scriptA $0:./scriptB $1:1 $2:2 $3:3 -- according to execve(2), only a single [arg] should be recognized: #! interpreter [arg] When an interpreter file is execve'd, the system actually execve's the specified interpreter. If the optional arg is specified, it becomes the first argument to the interpreter, and the name of the originally execve'd file becomes the second argument; otherwise, the name of the originally execve'd file becomes the first argument. The original argu- ments are shifted over to become the subsequent arguments. The zeroth argument is set to the specified interpreter. so the argv[] array in execve() should be loaded as: argv[0]=sh, argv[1]=scriptB, argv[2]=scriptA, and argv[3...]=command line args passed to scriptA. i read many many execve() man pages, and it seems like this is the way things should be. but in practice, it appears on many unix's, argv[] gets loaded additionally with any options given to a script (which is given as the [arg] to the interpreter) on the 1st line of a script. can anyone tell me if this is proper, and why or why not? there doesn't seem to be consistency across unix's. some ignore, or give an error if more than one [arg] exists on the 1st line of a script. The only thing I can find in IEEE Std 1003.1-2001 (aka SUSv3) is If the first line of a file of shell commands starts with the characters #!, the results are unspecified. which would indicate that there is no proper way of doing this. You may also want to have a look at bin/16393; at the bottom is a list of how some unices handle the situation. Your best bet at trying to be portable is to use at most one argument, no whitespace and no #. The PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=16393 $.02, /Mikko To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: #!/bin/sh execve
this does seem to be an ambiguous area. it seems more sane to allow arguments to a script given to an interpreter on the shebang line, passing everything after #!/interpreter [arg] off for eval or sh -c type parsing. i don't know how it breaks anything to load execve's argv[] with everything after the shebang, followed by command line options/args. but it sure muddies the water if you don't. otherwise there is a can of worms unnecessarily: #!/bin/sh -xthis is obviously ok. #!/bin/sh -vx this is obviously ok too. #!/bin/sh -cstringthis is currently not ok, but why shouldn't it be? #!/bin/sh -c string this is currently not ok, but why shouldn't it be? #!/bin/sh scriptthis is obviously ok. #!/bin/sh -n script this is currently not ok, but why shouldn't it be? #!/bin/sh script 1 2this is ok with FBSD and RH Linux, but not ok in a few implementations, but why shouldn't it be? it seems that only a minority of execve() man pages / implementations are preventing the sane solution ... The only thing I can find in IEEE Std 1003.1-2001 (aka SUSv3) is If the first line of a file of shell commands starts with the characters #!, the results are unspecified. which would indicate that there is no proper way of doing this. You may also want to have a look at bin/16393; at the bottom is a list of how some unices handle the situation. Your best bet at trying to be portable is to use at most one argument, no whitespace and no #. The PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=16393 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
