On Sun 25 Oct 2015 at 04:29:14 +, Juan R. de Silva wrote:
> > The packages cups-bsd, lpr, and lprng all have lpr. Try installing them
> > and removing them in turn, and see which works.
>
> Installation of cups-bsd did the trick.
So it should. For all practical purposes the lp and lpr comman
On 10/25/2015 05:29 AM, Juan R. de Silva wrote:
>> The packages cups-bsd, lpr, and lprng all have lpr. Try installing them
>> and removing them in turn, and see which works.
> Installation of cups-bsd did the trick.
>
> BTW, I tried installing lpr before and it did not help.
>
> This is weird, sin
> The packages cups-bsd, lpr, and lprng all have lpr. Try installing them
> and removing them in turn, and see which works.
Installation of cups-bsd did the trick.
BTW, I tried installing lpr before and it did not help.
This is weird, since I've looked into my i386 installation and neither
cup
On Sun, 25 Oct 2015 03:27:18 + (UTC), "Juan R. de Silva"
wrote:
> I have Jessie i386 and amd64 installed on 2 different laptops. Wine is
> installed on both, meaning that i386 architecture is enabled on amd64
> install.
>
> Both installation have access to the same printer using the same (
On Mon, 21 Sep 2009, Ali Jawad wrote:
> Just a quick Question, why does apache have a shell in passwd file
> on debian ?
not sure this answers your question, but you can't use that as a
login account since its entry in /etc/shadow has no legal password.
so, unless i'm missing something, i guess
on Mon, Nov 26, 2001 at 02:13:10AM +0100, A.R. (Tom) Peters ([EMAIL PROTECTED])
wrote:
> On Sun, 25 Nov 2001, Karsten M. Self wrote:
>
> > on Sun, Nov 25, 2001 at 02:22:13AM +0100, A.R. (Tom) Peters ([EMAIL
> > PROTECTED]) wrote:
> > > I tried to install the G77 compiler, and got the latest stuf
On Sun, 25 Nov 2001, Karsten M. Self wrote:
> on Sun, Nov 25, 2001 at 02:22:13AM +0100, A.R. (Tom) Peters ([EMAIL
> PROTECTED]) wrote:
> > I tried to install the G77 compiler, and got the latest stuff from
> > testing. It required a newer version of libc6 (2.2.4-5), which got
> > installed first
On Sun, Nov 25, 2001 at 07:58:34AM -0500, [EMAIL PROTECTED] wrote:
| I had a problem when I upgraded to the 2.4.12 kernel and the update asked
| whether I wanted to go with the default POSIX standard ash instead of bash. I
| answered yes, and then my automated dialup scripts wouldn't work for the
Try to find out if your /bin/sh is symbolically linked to bash, ash, korn, or
whatever other shell. /bin/sh should be just a symbolic link...if it isn't
linked, link it to something like bash.
I had a problem when I upgraded to the 2.4.12 kernel and the update asked
whether I wanted to go with th
on Sun, Nov 25, 2001 at 02:22:13AM +0100, A.R. (Tom) Peters ([EMAIL PROTECTED])
wrote:
> I tried to install the G77 compiler, and got the latest stuff from
> testing. It required a newer version of libc6 (2.2.4-5), which got
> installed first. Then all subsequent packages failed. I cannot open
> "Dragos" == Dragos Delcea <[EMAIL PROTECTED]> writes:
Dragos> I know that, but I'm courious: why /etc/passwd didn't came
Dragos> with /bin/false as default setting (I'm talking about system
Dragos> accounts that really don't use/need the shell)
There are some programs which rely on the fact
Paul Rae wrote:
>
> the /bin/flase shell is there, when you add a user you decide what shell
> they have, if you dont want them to have a shell edit the passwd file and
> make any changes you feel are needed
>
I know that, but I'm courious: why /etc/passwd didn't came with
/bin/false as default s
the /bin/flase shell is there, when you add a user you decide what shell
they have, if you dont want them to have a shell edit the passwd file and
make any changes you feel are needed
-Original Message-
From: Dragos Delcea
To: debian-user@lists.debian.org
Sent: 14/06/01 11:11
Subject: /bin
Dragos Delcea wrote:
>
> hello list,
>
> why in debian (I have 2.2r3) all the system users have
> a sh shell?
> I have various other linuxes, a freebsd, and none has
> this settings in /etc/passwd...; I want to know the
> reason behind this, 'couse I've heard and it seems
> resonable that it offe
The X-Windows problem is solved here, now (well, solved
user-wise).
I found the XFree86.0.log file in /var/log/ and had a
look through it. It showed that cyrillic fonts were missing,
so I installed cyrillic fonts and reloaded configs. It
worked. In any case, if others are having the same pr
I forgot how to list the startup information (errors, etc.)
for X-Windows. ...anyone remember how to do this? ...might
help with a solution. CC me with the answer, please. Thanks.
Art Lemasters
--- Alessandro Ghigi <[EMAIL PROTECTED]> wrote:
>
> Hi I am using woody and I am having the same
Hi I am using woody and I am having the same problem. Last Sunday I did an
upgrade and got the new XFree 4. Since then quite a few things have been
getting worse and worse. The worst is that since 2 days starting X makes the
screen black and the machine locks-up. Actually I don't think the mach
On Sat, Nov 11, 2000 at 03:20:50PM -0800, Art Lemasters wrote:
> I am running woody.
>
> Running dselect in apt access mode, none of the upgrade
> packages will install. I also tried running apt-get.
> The error message when trying to install is
>
> ~~
I solved the problem by reinstalling perl 5.6 via dpkg.
Now there is another serious problem. When x-windows
starts up via xdm, the screen goes blank and the whole
machine locks-up. I had to use the rescue disk to mount
the hard drive and stop xdm from starting to reboot, get
into lynx and s
*- On 2 Jan, Ben Collins wrote about "Re: /bin/sh and ash, bash"
> On Sun, Jan 02, 2000 at 03:34:51PM -0600, matt garman wrote:
>>
>> I noticed that Debian makes /bin/sh a symlink to /bin/bash by default.
>> I'd rather have /bin/sh link to /bin/ash. I tri
On Sun, Jan 02, 2000 at 03:34:51PM -0600, matt garman wrote:
>
> I noticed that Debian makes /bin/sh a symlink to /bin/bash by default.
> I'd rather have /bin/sh link to /bin/ash. I tried this quite a while
> ago, and it seems as though some Debian-specific scripts rely on /bin/sh
> actually bein
When it comes to having a root shell for emergency use, you may look
into sash, which is intended to be used even when libc is broken:
Package: sash
Priority: optional
Section: shells
Installed-Size: 299
Maintainer: Raul Miller <[EMAIL PROTECTED]>
Architecture: i386
Version: 2.1-5
Size: 131400
D
>
> And, if I remember correctly, package maintainers whose packages break
> with ash as /bin/sh are more than willing to make their scripts and
> such work with ash as your /bin/sh.
>
More so if you point out the cause or send patches.
The big offenders are:
function foo() instead of foo()
pr
FYI Debian policy states that if you call /bin/sh in a script, it should be a
bourne script and not a bash script -- so if anything fails submit a bug report.
YAY another believer (-:
I use ash as my sh on all boxen I admin. Only hassle is occasional bash-isms
(submit bugs and they get fixed) and that updates of bash overwrite my /bin/sh
link.
On Mon, Mar 15, 1999 at 03:01:48PM -0500, Noah L. Meyerhans wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
> OK, I am sure this has been discussed to death at some point, but I just
> have to ask: Is it really a good idea to have /bin/sh a symlink to bash?
> I know bash is a nicer shell to use, an
Hi,
>>"Torsten" == Torsten Hilbrich <[EMAIL PROTECTED]> writes:
Torsten> The . command in the ash do not support command line options to the
Torsten> called script (Does anyone have the Posix standard for the bourne
Torsten> shell handy?)
Nope, command line options are not required to
Hi,
>>"the" == the lone gunman <[EMAIL PROTECTED]> writes:
the> On Wed, Aug 26, 1998 at 08:46:38AM +0200, Torsten Hilbrich wrote:
>> I recently installed an other shell than bash as /bin/sh (ash
>> precisly) just to test the systems behaviour and noticed that some
>> scripts stopped working co
On: 27 Aug 1998 19:02:43 +0200 Torsten Hilbrich writes:
>
> On: Wed, 26 Aug 1998 15:18:36 -0400 Shaleh writes:
>>
>> Yes, if it calls sh, it should only use sh features. Report a bug.
>> Please show which line fails and if possible a way to make it sh
>> compliant. I use ash as my /bin/sh w/o
On: Wed, 26 Aug 1998 15:18:36 -0400 Shaleh writes:
>
> Yes, if it calls sh, it should only use sh features. Report a bug.
> Please show which line fails and if possible a way to make it sh
> compliant. I use ash as my /bin/sh w/o a hitch. apt has a small
> bug that is only cosmetic.
The probl
On Wed, Aug 26, 1998 at 02:12:39PM -0500, the lone gunman wrote:
> I've heard of folks getting faster boot times when they link /bin/sh
> to /bin/ash instead of bash.
Are faster boot times an issue even worth thinking about?
One of my boxes takes ages to boot (it has a soundblaster-type CD-ROM
dr
Yes, if it calls sh, it should only use sh features. Report a bug.
Please show which line fails and if possible a way to make it sh
compliant. I use ash as my /bin/sh w/o a hitch. apt has a small bug
that is only cosmetic.
Torsten Hilbrich wrote:
>
> I recently installed an other shell than b
> Is this[1] to be considered as a bug and should I report it?
>
> Torsten
>
> Footnotes:
> [1] the using of non-sh features in a script started with #!/bin/sh
Yes, this is a bug! Please report it.
Even more, we had a BIG discussion of this issue and dicided to have an
alternatives for /
On Wed, Aug 26, 1998 at 08:46:38AM +0200, Torsten Hilbrich wrote:
> I recently installed an other shell than bash as /bin/sh (ash
> precisly) just to test the systems behaviour and noticed that some
> scripts stopped working correctly. For example, /etc/init.d/rcS had
> problems executing some scr
Craig Sanders <[EMAIL PROTECTED]> writes:
> /bin/sh and /bin/bash are not equivalent. bash is a superset of sh
> functionality. bash behaves differently depending on whether it is
> invoked as sh or as bash (at least the new version 2 does).
>
> bash when invoked as /bin/sh is more posix complian
Carey Evans ([EMAIL PROTECTED]) wrote on 14 March 1997 13:32:
>Here (with gzip 1.2.4-14) the postinst script is for /bin/sh.
>I suspect the problem is the line in /etc/zshenv:
>
>PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:."
>
>which means that every time zsh is used, /usr
On Wed, 12 Mar 1997, Steve wrote:
> The problem is that the scripts only work with bash in sh mode and not
> with sh-compatible shells such as ash. Try making /bin/sh a symlink to
> /bin/ash and reboot. You'll get error messages from the startup
So if these script doesn't work with ash nor zsh in
[EMAIL PROTECTED] writes:
[snip]
> The only problem is that some packages, such as gzip, give an error
> in the perl (!!??) postinst script.
Here (with gzip 1.2.4-14) the postinst script is for /bin/sh.
I suspect the problem is the line in /etc/zshenv:
PATH="/usr/local/bin:/usr/bin:/bin:/us
zsh can be used as sh instead of bash for almost everything. I have
two machines here where /bin/sh is a link to /bin/zsh. This makes
apsfilter work. bash gives an error in a pipe, complaining about some
signal. It's a bash bug; with zsh it works. The only problem is that
some packages, such as gzi
Maybe either the scripts are so old that they were never updated when
newer shells besides bash came out, or maybe they assumed that all newer
shells would be bash-compatible, or maybe the people who wrote them are
just stupid :) Not everyone's a genius you know :)
On Wed, 12 Mar 1997, Steve wrot
On Mar 03, 1997 at 01:45:37PM -0800, Steve wrote:
> > I set my system shell to zsh as well, and replaced all the /bin/bash in
> > /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to point to
> > /usr/bin/zsh, all of the /etc/init.d/* scripts blew up.
>
> If those scripts actually requ
> > If those scripts actually require bash then why isn't the first line
> > #!/bin/bash? Is this a bug, or is it written in stone that /bin/sh and
> > /bin/bash are equivalent?
>
> /etc/init.d/* do, in fact, all start with "#!/bin/sh" as they should.
> I believe that bash was written to be a free
On Wed, 12 Mar 1997, Steve wrote:
> > I set my system shell to zsh as well, and replaced all the /bin/bash
> > in /etc/passwd to /usr/bin/zsh, but when I tried to move /bin/sh to
> > point to /usr/bin/zsh, all of the /etc/init.d/* scripts blew up.
>
> If those scripts actually require bash then w
43 matches
Mail list logo
