Is this a bug?
No. sudo
has no knowledge of commands that are built in to the various shells, like ulimit
and cd
.
You've been presented with two ways of addressing this — using a shell as an intermediary and adjusting the limits elsewhere than on the command line itself. Here is a third, for the situations when one is trying to use such commands to make modifications to process state rather than to display it.
If one could run the shell builtins as sudo ulimit …
or sudo cd …
to actually modify process state, that would not be particularly useful. That would run nothing else afterwards, in the process whose limits or working directory had been changed. One would adjust process limits or working directory only to immediately exit the process.
But there are toolsets with chain-loading external commands with these functions. They do the same thing as the shell builtins but also chain load to another program after they have done so.
They are the various daemontools-family toolsets — daemontools, daemontools-encore, nosh, perp, s6, freedt, and runit.
The tools for setting limits and then chain loading to another program are variously softlimit
(daemontools), softlimit
(freedt), softlimit
(daemontools-encore) softlimit
(nosh), s6-softlimit
(s6), chpst
(runit), and runlimit
(perp). So one could run, say, vim with an altered core file size limit using daemontools, daemontools-encore, nosh, or freedt with the command:
sudo softlimit -c 0 vim
nosh also has a similar ulimit
command that uses different unit sizes for the various limits to the ones used with softlimit
:
sudo ulimit -c 0 vim
The same goes for changing directory, for which there are the nosh chdir
external chain-loading command:
sudo chdir /etc vim rc.local
and the cd
external command from execline:
sudo /command/cd /etc vim rc.local
sudo bash -c ulimit
– ssta Oct 16 '15 at 22:26