Bug 4071 - error message starting tcsh from ksh
Summary: error message starting tcsh from ksh
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pdksh
Version: 5.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-07-16 14:02 UTC by Dan Yocum
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-15 18:15:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Dan Yocum 1999-07-16 14:02:31 UTC
When ksh is used as the login shell and tcsh is invoked
sometime thereafter within a shell or terminal this error
message appears:

limit: coredumpsize: Can't set limit

This does not occur when you change shell in a terminal to
ksh and then to tcsh - only when ksh is the login shell.

This has existed at least since 5.0

Cheers,
Dan

Comment 1 David Lawrence 1999-07-16 18:09:59 UTC
I have verified that this does occur as reported on a standard 6.0
install. It is being assigned to a developer for further review.

Comment 2 Jeff Johnson 1999-08-20 22:32:59 UTC
*** This bug has been marked as a duplicate of 4582 ***

Comment 3 Anonymous 1999-08-26 22:06:59 UTC
From an expert here at the Lab.  Enjoy.  Dan

The ulimit -c and limit coredumpsize values on trocious and bldlinux52
were both set to 1000000, but since these are in different units
(blocks and kbytes, respectively), they are inconsistent.  The
difference is only noticeable if your shell is sh/ksh/bash, and then
you switch to csh/tcsh, which gives an ugly error message, since
you're then attempting to double your quota, and it fails
to execute your .cshrc file.

The value in the /etc/profile files needs to be twice the value in the
/etc/csh.cshrc file, and I have made that change on trocious and
bldlinux52.

I believe on the latest 5.2 release, the value is being set in
/etc/bashrc, rather than /etc/profile, but it should be fixed wherever
it lives.


Note You need to log in before you can comment on or make changes to this bug.