John Hardin wrote:
> Bob Proulx wrote:
> > John Hardin wrote:
> > > Bob Proulx wrote:
> > > > And that is also why I don't understand the move from /bin/* to
> > > > /usr/bin/* and the same for lib and others. That makes the "usr" part
> > > > completely useless. It would be better to move everyt
Am 06.02.2015 um 01:55 schrieb Martin Gregorie:
On Fri, 2015-02-06 at 00:38 +0100, Reindl Harald wrote:
you did not get the point
there is also /usr/local/bin, /usr/local/sbin and so on
You don't. You avoid name and version clashes by NOT putting distro
packages on /usr/local and ONLY putting
> ICL mainframes for me: 1900 initially, then 2903 (in NYC would you
> believe) and then 2966 medium rang iron into the early 80. Even the '66s
> were using EDS200 and EDS640s.
>
At the risk of going violently off topic I'd just like to say that,
should you want to see one of these large, burnt-or
On Fri, 06 Feb 2015 01:48:53 +
Martin Gregorie wrote:
> ICL mainframes for me: 1900 initially, then 2903 (in NYC would you
> believe) and then 2966 medium rang iron into the early 80. Even the
> '66s were using EDS200 and EDS640s.
Oooh, are we comparing greybeards? (I don't have a beard any
On Thu, 2015-02-05 at 20:02 -0500, Rick Macdougall wrote:
> Hi,
>
> First HPUX 900 certified admin in Canada circa 1982. I too remember those
> days.
>
ICL mainframes for me: 1900 initially, then 2903 (in NYC would you
believe) and then 2966 medium rang iron into the early 80. Even the '66s
wer
Hi,
First HPUX 900 certified admin in Canada circa 1982. I too remember those days.
Regards,
Rick
PS. Still under 50 :)
Sent from my iPad
> On Feb 5, 2015, at 7:37 PM, Martin Gregorie wrote:
>
>> On Thu, 2015-02-05 at 16:06 -0700, Bob Proulx wrote:
>>
>> Not quite. It was due to the phy
On Fri, 2015-02-06 at 00:38 +0100, Reindl Harald wrote:
>
> you did not get the point
> there is also /usr/local/bin, /usr/local/sbin and so on
>
You don't. You avoid name and version clashes by NOT putting distro
packages on /usr/local and ONLY putting local and 3rd party developed
non-standard
On Thu, 2015-02-05 at 16:06 -0700, Bob Proulx wrote:
> Not quite. It was due to the physically small sizes of the media
> available at the time. Therefore by necessity what would fit would
> fit on the root disk and then the system would bootstrap itself to the
> full system with more disks.
>
On Thu, 2015-02-05 at 14:50 -0700, Bob Proulx wrote:
> I think it should be /bin/sh because standard is better than better.
> They are producing gratuitous system differences for no good reason.
>
If you're using the RedHat Linux or its clones you may have noticed
that /bin/bash and /usr/bin/sh bo
On Thu, 5 Feb 2015, Bob Proulx wrote:
John Hardin wrote:
Bob Proulx wrote:
And that is also why I don't understand the move from /bin/* to
/usr/bin/* and the same for lib and others. That makes the "usr" part
completely useless. It would be better to move everything from
/usr/bin/* up to /bi
Am 06.02.2015 um 00:06 schrieb Bob Proulx:
Reindl Harald wrote:
complete nonsense
you can not move anything below /usr/ in the rootfs and if it only because
/usr/local and only move the contents of /usr/bin/ around breaks most setups
and shebangs - get rid of /bin and /sbin while place symlin
Reindl Harald wrote:
> schrieb Bob Proulx:
> >They are producing gratuitous system differences for no good reason.
>
> not true - hence the symlink and "they" are in the meantime not only fedora,
> google will show
>
> >And that is also why I don't understand the move from /bin/* to
> >/usr/b
John Hardin wrote:
> Bob Proulx wrote:
> > And that is also why I don't understand the move from /bin/* to
> > /usr/bin/* and the same for lib and others. That makes the "usr" part
> > completely useless. It would be better to move everything from
> > /usr/bin/* up to /bin/* instead and the same
On Thu, 5 Feb 2015, Bob Proulx wrote:
And that is also why I don't understand the move from /bin/* to
/usr/bin/* and the same for lib and others. That makes the "usr" part
completely useless. It would be better to move everything from
/usr/bin/* up to /bin/* instead and the same for lib and th
Am 05.02.2015 um 22:50 schrieb Bob Proulx:
Reindl Harald wrote:
schrieb Bob Proulx:
Seeing SHELL=/usr/bin/bash I must comment that the setting is quite
unusual. It would normally be /bin/sh. Or on some systems be
/bin/bash. It is quite unusual to see /usr/bin/bash there
it was /bin/bash i
Reindl Harald wrote:
> schrieb Bob Proulx:
> > Seeing SHELL=/usr/bin/bash I must comment that the setting is quite
> > unusual. It would normally be /bin/sh. Or on some systems be
> > /bin/bash. It is quite unusual to see /usr/bin/bash there
>
> it was /bin/bash in the past but why should i def
Am 05.02.2015 um 18:46 schrieb LuKreme:
On Feb 5, 2015, at 2:28 AM, Reindl Harald wrote:
[root@srv-rhsoft:~]$ cat /etc/crontab
SHELL=/usr/bin/bash
PATH=/usr/bin:/usr/sbin
LANG=en_GB.UTF-8
MAILTO=root
HOME=/
PODCAST_THREADS=6
Ah, no, I’ve never touched /etc/crontab. I use sudo crontab -e to e
Am 05.02.2015 um 18:44 schrieb Bob Proulx:
Seeing SHELL=/usr/bin/bash I must comment that the setting is quite
unusual. It would normally be /bin/sh. Or on some systems be
/bin/bash. It is quite unusual to see /usr/bin/bash there
it was /bin/bash in the past but why should i define a path p
On Feb 5, 2015, at 2:28 AM, Reindl Harald wrote:
> [root@srv-rhsoft:~]$ cat /etc/crontab
> SHELL=/usr/bin/bash
> PATH=/usr/bin:/usr/sbin
> LANG=en_GB.UTF-8
> MAILTO=root
> HOME=/
> PODCAST_THREADS=6
Ah, no, I’ve never touched /etc/crontab. I use sudo crontab -e to edit the
user-level crontab for
Reindl Harald wrote:
>
> schrieb LuKreme:
> >Bob Proulx wrote:
> > > The syntax "variable=value command" is a /bin/sh syntax which sets the
> > > variable for just that command. In the above sa-update would get the
> > > PATH setting. But then && terminates that command.
> >
> > I’m actually not
LuKreme wrote:
> Bob Proulx wrote:
> > The syntax "variable=value command" is a /bin/sh syntax which sets the
> > variable for just that command. In the above sa-update would get the
> > PATH setting. But then && terminates that command.
>
> I’m actually not positive that is the case.
I am posi
On Thu, 2015-02-05 at 09:55 -0500, Kevin A. McGrail wrote:
> On 2/5/2015 9:03 AM, Benny Pedersen wrote:
> > Kevin A. McGrail skrev den 2015-02-05 14:18:
> >> Rather than learning more about how path and cron works, perhaps just
> >> symlink things like gpg to /usr/bin might be easier. Gpg is used t
Am 05.02.2015 um 16:17 schrieb Kevin A. McGrail:
On 2/5/2015 8:56 AM, Martin Gregorie wrote:
On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote:
Rather than learning more about how path and cron works, perhaps just
symlink things like gpg to /usr/bin might be easier. Gpg is used to
ver
Am 05.02.2015 um 16:20 schrieb Benny Pedersen:
Kevin A. McGrail skrev den 2015-02-05 15:55:
I'd be a pot calling a kettle black because I use /usr/local all the
time to build on top of distros.
make install, defaults to /usr/local, but distros must not use that prefix
what exactly did you
Kevin A. McGrail skrev den 2015-02-05 15:55:
I'd be a pot calling a kettle black because I use /usr/local all the
time to build on top of distros.
make install, defaults to /usr/local, but distros must not use that
prefix
working with freebsd lately ? :=)
On 2/5/2015 8:56 AM, Martin Gregorie wrote:
On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote:
Rather than learning more about how path and cron works, perhaps just symlink
things like gpg to /usr/bin might be easier. Gpg is used to verify the
authenticity of the update.
Regards,
KAM
On 2/5/2015 9:03 AM, Benny Pedersen wrote:
Kevin A. McGrail skrev den 2015-02-05 14:18:
Rather than learning more about how path and cron works, perhaps just
symlink things like gpg to /usr/bin might be easier. Gpg is used to
verify the authenticity of the update.
or remove bad installers of g
Kevin A. McGrail skrev den 2015-02-05 14:18:
Rather than learning more about how path and cron works, perhaps just
symlink things like gpg to /usr/bin might be easier. Gpg is used to
verify the authenticity of the update.
or remove bad installers of gpg ? :=)
http://en.wikipedia.org/wiki/Files
On Thu, 2015-02-05 at 08:18 -0500, Kevin A. McGrail wrote:
> Rather than learning more about how path and cron works, perhaps just symlink
> things like gpg to /usr/bin might be easier. Gpg is used to verify the
> authenticity of the update.
> Regards,
> KAM
>
On my machines anyway, gpg is in /u
Rather than learning more about how path and cron works, perhaps just symlink
things like gpg to /usr/bin might be easier. Gpg is used to verify the
authenticity of the update.
Regards,
KAM
On Thu, 2015-02-05 at 01:21 -0700, LuKreme wrote:
> > On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote:
> # /bin/sh
> # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/us
Am 05.02.2015 um 09:21 schrieb LuKreme:
On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote:
LuKreme wrote:
The front actin simply calls sa-update. Do I just
16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update &&
/usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd rest
> On Feb 5, 2015, at 1:03 AM, Bob Proulx wrote:
>
> LuKreme wrote:
>> The front actin simply calls sa-update. Do I just
>>
>> 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update
>> && /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart
>>
>> ?
>>
>> Or i
LuKreme wrote:
> The front actin simply calls sa-update. Do I just
>
> 16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update &&
> /usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart
>
> ?
>
> Or is there a reason not to do that?
The syntax "variable=value co
On Feb 4, 2015, at 9:21 PM, Kevin A. McGrail wrote:
> Define your path in the cron script.
The front actin simply calls sa-update. Do I just
16 1 * * * PATH=/usr/bin:/bin:/usr/local/bin /usr/local/bin/sa-update &&
/usr/local/bin/sa-compile && /usr/local/etc/rc.d/sa-spamd restart
?
Or is
Define your path in the cron script.
LuKreme wrote:
>
>> On Feb 4, 2015, at 8:34 PM, David B Funk
> wrote:
>>
>> On Wed, 4 Feb 2015, LuKreme wrote:
>>
>>> On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote:
Perhaps /usr/local/bin is not on PATH for the cron user?
>>>
>>> I don’t understand what
> On Feb 4, 2015, at 8:34 PM, David B Funk wrote:
>
> On Wed, 4 Feb 2015, LuKreme wrote:
>
>> On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote:
>>> Perhaps /usr/local/bin is not on PATH for the cron user?
>>
>> I don’t understand what you are saying. The crontab lists the full path.
>>
# cro
On Wed, 4 Feb 2015, LuKreme wrote:
On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote:
Perhaps /usr/local/bin is not on PATH for the cron user?
I don’t understand what you are saying. The crontab lists the full path.
# crontab -l |grep sa-update
16 1 * * * /usr/local/bin/sa-update && /usr/l
On Feb 4, 2015, at 8:57 AM, Joe Quinn wrote:
> Perhaps /usr/local/bin is not on PATH for the cron user?
I don’t understand what you are saying. The crontab lists the full path.
>> # crontab -l |grep sa-update
>> 16 1 * * * /usr/local/bin/sa-update && /usr/local/bin/sa-compile &&
>> /usr/l
Perhaps /usr/local/bin is not on PATH for the cron user?
On 2/4/2015 10:50 AM, LuKreme wrote:
Cron is sending me an error:
error: gpg required but not found! It is not recommended, but you can use
"sa-update" with the --no-gpg to skip the verification.
However, if I run sa-update -D from the
40 matches
Mail list logo
