Re: /bin/date and coreutils
Just a side note: as stated in sed(1) and gnused(1) manpages, I'm pretty sure sed -E is the same as gnused -r. N_Ox. Le 7 mai 07 à 20:52, David Liontooth a écrit : In the case of sed, I needed the -r switch and found gsed, providing gnused, in macports, which works great. Dave ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: scripting environments (was: /bin/date and coreutils)
On 2007-05-11 00:27:54 +0200, Jochen Küpper wrote: On 10.05.2007, at 23:56, Vincent Lefevre wrote: And Python isn't installed everywhere. Well, that's not my experience. It's even on all number crunchers and big iron machines I have used over the last years, as scheduling/batch systems also use it;) Well, I have an access to a Solaris machine, where perl is installed but not python. The system version is used, and this is not necessarily a problem, except if some modules only present in MacPorts are used. That's the real point - you are in principle back to the same point as with shell scripts - unless you use only the basic stuff. No, with Perl, one can do very much without using modules (even much more than shell scripts and the standard utilities), and many modules are provided in standard, so that using the system version would not be a problem in practice. If you do that in a shell-script (using only basic stuff), you are as safe, because /bin/bash and /bin/tcsh are always there... They are always there under Mac OS X. But some Unix platforms do not necessarily have a /bin/bash (e.g. Solaris). And I don't think this is the case of tcsh either (/bin/csh is probably much more common, but anyway http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/). /bin/sh is always there, but this is not always a POSIX sh (e.g. it isn't under Solaris). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: scripting environments (was: /bin/date and coreutils)
On 2007-05-11 18:12:35 +0200, Elias Pipping wrote: On May 11, 2007, at 9:13 AM, Vincent Lefevre wrote: They are always there under Mac OS X. But some Unix platforms do not necessarily have a /bin/bash (e.g. Solaris). And I don't think this is the case of tcsh either (/bin/csh is probably much more common, but anyway http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/). /bin/sh is always there, but this is not always a POSIX sh (e.g. it isn't under Solaris). any reason not to use '/usr/bin/env bash'? Because a standard Solaris installation doesn't have bash installed anywhere. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: scripting environments (was: /bin/date and coreutils)
On May 11, 2007, at 7:12 PM, Marc André Selig wrote: On 5/11/07, Elias Pipping [EMAIL PROTECTED] wrote: a system that doesn't have bash anywhere should be considered broken ;) Is there really a macports user on solaris? The thread was about making scripts portable, not about making them work on OS X only. I don't use MacPorts on Solaris (why should I), but I do write things that have to work on several platforms, including OS X and Solaris. Regards, Marc Indeed, I'm missing the point. So... make a script that can live with the bourne shell invoke /bin/sh then and if it can't, make it invoke '/usr/bin/env bash' because if bash needs to be invoked at all cost, that's the best way to do it. Regards, Elias___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: scripting environments (was: /bin/date and coreutils)
On 2007-05-11 20:25:24 +0200, Elias Pipping wrote: Indeed, I'm missing the point. So... make a script that can live with the bourne shell invoke /bin/sh then The script must be compatible with both Bourne and POSIX shells (because under Solaris, /bin/sh is a Bourne shell). and if it can't, make it invoke '/usr/bin/env bash' because if bash needs to be invoked at all cost, that's the best way to do it. Then it's better to invoke /usr/bin/env perl, which is much more powerful than bash. BTW, you can't implement things like timeouts (e.g. if some command takes too much time to complete) in POSIX shells, because if you want to trap a signal, then the trap function will be executed only when the current command has terminated! -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
On 2007-05-07 12:13:43 -0700, David Liontooth wrote: sorry for thinking it was so unlikely this was ported that I didn't even look! I'll be interested to see what's included. This is very cool, as it allows my scripts to be crossplatform. But you need to use the with_default_names variant *and* have $prefix/bin in your path first, because gdate doesn't exist under Linux. If your scripts run in background, there's some risk of race condition when coreutils is upgraded (because the old version is deactivated before the new one is activated). And you never know if there will be changes under Linux (for instance, coreutils provides a hostname command, but Linux currently uses another one). For all these reasons (and the fact that the output of the shell commands depends on the locales), I think that it is a better idea to use Perl instead of shell scripts if you want portable scripts. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
On 2007-05-10 23:19:50 +0200, Jochen Küpper wrote: On 10.05.2007, at 16:25, Vincent Lefevre wrote: I think that it is a better idea to use Perl instead of shell scripts if you want portable scripts. or Python (my personal favorite;), or ... I've seen many problems after Python upgrades under Debian (e.g. things that no longer work, probably because incompatibilities between versions)... And Python isn't installed everywhere. Anyhow, what's happening during an perl (python, ...) update? The system version is used, and this is not necessarily a problem, except if some modules only present in MacPorts are used. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
scripting environments (was: /bin/date and coreutils)
On 10.05.2007, at 23:56, Vincent Lefevre wrote: And Python isn't installed everywhere. Well, that's not my experience. It's even on all number crunchers and big iron machines I have used over the last years, as scheduling/ batch systems also use it;) And it's a fabulous matlab replacement for data extraction. Anyway, I guess this is getting off-topic. The system version is used, and this is not necessarily a problem, except if some modules only present in MacPorts are used. That's the real point - you are in principle back to the same point as with shell scripts - unless you use only the basic stuff. If you do that in a shell-script (using only basic stuff), you are as safe, because /bin/bash and /bin/tcsh are always there... Greetings, Jochen -- Einigkeit und Recht und Freiheithttp://www.Jochen- Kuepper.de Liberté, Égalité, FraternitéGnuPG key: CC1B0B4D Sex, drugs and rock-n-roll PGP.sig Description: This is a digitally signed message part ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
2007/5/8, David Liontooth [EMAIL PROTECTED]: Are there disadvantages to installing coreutils -- does it or could it interefere with other programs? I'm a bit queasy, but I guess as long as /opt/local/bin is last in the path it won't interfere. In fact, if I understand correctly the portfile, the coreutils port install all GNU utilties with a 'g' prefix ( ls is installed as /opt/local/bin/gls , and so on) . So there shouldn't be a conflict with the native utilities. There's a variant 'with_default_names' that also create links between the g-name and the native name (it creates a link from /opt/local/bin/ls to /opt/local/bin/gls). Didier. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
Didier Arenzana wrote: 2007/5/8, David Liontooth [EMAIL PROTECTED]: Are there disadvantages to installing coreutils -- does it or could it interefere with other programs? I'm a bit queasy, but I guess as long as /opt/local/bin is last in the path it won't interfere. In fact, if I understand correctly the portfile, the coreutils port install all GNU utilties with a 'g' prefix ( ls is installed as /opt/local/bin/gls , and so on) . So there shouldn't be a conflict with the native utilities. There's a variant 'with_default_names' that also create links between the g-name and the native name (it creates a link from /opt/local/bin/ls to /opt/local/bin/gls). Nice, thanks. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
/bin/date and coreutils
In OSX, /bin/date doesn't support the -d switch date: illegal option -- d In the case of sed, I needed the -r switch and found gsed, providing gnused, in macports, which works great. The date utility is bundled in coreutils on debian, along with cat chown df ln and so on -- I imagine this can't easily be ported? Details: I run a certain job daily, which puts the results in a directory named by that day's date. In a script operating on these results, I need to indicate which directory to work on by how many days ago it was created. So I might set up this command in cron: work 4 to run the script work in the directory created four days ago. To pick the date, I use DAY=$(date -d -$1 day +%F) The -d switch allows me to subtract days (or minutes or seconds) from today's date. Is there a way to subtract n days from a date using the OSX date utility? Dave ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
On 5/7/07, David Liontooth [EMAIL PROTECTED] wrote: In OSX, /bin/date doesn't support the -d switch But it does have the -r switch. ;-) [...] To pick the date, I use DAY=$(date -d -$1 day +%F) The -d switch allows me to subtract days (or minutes or seconds) from today's date. Is there a way to subtract n days from a date using the OSX date utility? Something like this? date -r `date +%s-n*24*60*60|bc` +%F Regards, Marc ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
On May 7, 2007, at 11:52 AM, David Liontooth wrote: The date utility is bundled in coreutils on debian, along with cat chown df ln and so on -- I imagine this can't easily be ported? I think you're covered: port info coreutils coreutils 6.9, sysutils/coreutils (Variants: universal, with_default_names, nls) http://www.gnu.org/software/coreutils/ The GNU Core Utilities are the basic file, shell, and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. Library Dependencies: libiconv -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem? PGP.sig Description: This is a digitally signed message part ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
Marc André Selig wrote: On 5/7/07, David Liontooth [EMAIL PROTECTED] wrote: In OSX, /bin/date doesn't support the -d switch But it does have the -r switch. ;-) [...] To pick the date, I use DAY=$(date -d -$1 day +%F) The -d switch allows me to subtract days (or minutes or seconds) from today's date. Is there a way to subtract n days from a date using the OSX date utility? Something like this? date -r `date +%s-n*24*60*60|bc` +%F Regards, Marc Wow, that was fast! So I have a way to do it with the native coreutils. Dave ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: /bin/date and coreutils
paul beard wrote: On May 7, 2007, at 11:52 AM, David Liontooth wrote: The date utility is bundled in coreutils on debian, along with cat chown df ln and so on -- I imagine this can't easily be ported? I think you're covered: port info coreutils coreutils 6.9, sysutils/coreutils (Variants: universal, with_default_names, nls) http://www.gnu.org/software/coreutils/ The GNU Core Utilities are the basic file, shell, and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system. Previously these utilities were offered as three individual sets of GNU utilities, fileutils, shellutils, and textutils. Those three have been combined into a single set of utilities called the coreutils. Library Dependencies: libiconv Thanks, Paul -- sorry for thinking it was so unlikely this was ported that I didn't even look! I'll be interested to see what's included. This is very cool, as it allows my scripts to be crossplatform. Dave -- Paul Beard words: http://paulbeard.org/wordpress pictures: http://www.flickr.com/photos/pdb206/ Are you trying to win an argument or solve a problem? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
