15 Jul
2016
15 Jul
'16
5:56 a.m.
On Jul 14, 2016 7:01 PM, "Peter Jeremy" <peter(a)rulingia.com> wrote:
builtin
On 2016-Jul-15 08:36:56 +1000, Dave Horsfall <dave(a)horsfall.org> wrote:
>On Thu, 14 Jul 2016, Clem Cole wrote:
And on the Mac
and FreeBSD, they still are (as well as being builtins).
FreeBSD provides a convenient list of what commands are (currently) to the provided shells and available externally:
https://www.freebsd.org/cgi/man.cgi?builtin
Bash man page does as well along with command -v (and hash IIRC) letting
you know.
I've always been curious though - what was the reason behind implementing
/bin/[ ? IDK any shell where this isn't implemented - I always assumed it's
a POSIX compatibility stopgap older systems needed to stay compliant with
their shipped shell.
15 Jul
15 Jul
7:04 a.m.
New subject: Shell control through external commands
On Thu, 14 Jul 2016, shawn wilson wrote:
I've always been curious though - what was the
reason behind
implementing /bin/[ ? IDK any shell where this isn't implemented - I
always assumed it's a POSIX compatibility stopgap older systems needed
to stay compliant with their shipped shell.
To implement:
[ blah ]
when it wasn't a built-in (there were few built-ins in those days).
I have no idea why it's still there... A Posix requirement, along with
really unsafe functions?
By the way, on both Mac and FreeBSD (I can't be bothered checking my
Penguin box) "true" and "false" are binaries (and aren't even
linked).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
7:22 a.m.
New subject: Shell control through external commands
On Fri, 15 Jul 2016, Dave Horsfall wrote:
On Thu, 14 Jul 2016, shawn wilson wrote:
$ file $(which true) $(which false)
/bin/true: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x347aaa1fa815d6689723e6f8aa0f7207566b6aba, stripped
/bin/false: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x821c6a0a4331413fb4b562b623c6bd5ca0a707f6, stripped
-uso.
I've always been curious though - what was
the reason behind
implementing /bin/[ ? IDK any shell where this isn't implemented - I
always assumed it's a POSIX compatibility stopgap older systems needed
to stay compliant with their shipped shell.
To implement:
[ blah ]
when it wasn't a built-in (there were few built-ins in those days).
I have no idea why it's still there... A Posix requirement, along with
really unsafe functions?
By the way, on both Mac and FreeBSD (I can't be bothered checking my
Penguin box) "true" and "false" are binaries (and aren't even
linked).
8:25 a.m.
New subject: Shell control through external commands
Dave Horsfall <dave(a)horsfall.org> wrote:
On Thu, 14 Jul 2016, shawn wilson wrote:
Consider
execlp("[", "-f", "/some/file", "]", NULL);
Then [ and test need to live in the filesystem.
Arnold
I've always been curious though - what was
the reason behind
implementing /bin/[ ? IDK any shell where this isn't implemented - I
always assumed it's a POSIX compatibility stopgap older systems needed
to stay compliant with their shipped shell.
To implement:
[ blah ]
when it wasn't a built-in (there were few built-ins in those days).
I have no idea why it's still there... A Posix requirement, along with
really unsafe functions?
16 Jul
16 Jul
12:26 p.m.
New subject: Shell control through external commands
On Thu, 14 Jul 2016, arnold(a)skeeve.com wrote:
Consider
execlp("[", "-f", "/some/file", "]", NULL);
Then [ and test need to live in the filesystem.
Ah yes, of course... Thanks.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
15 Jul
15 Jul
8:25 a.m.
New subject: Shell control through external commands
On Thu, Jul 14, 2016, at 19:56, shawn wilson wrote:
I've always been curious though - what was the
reason behind
implementing /bin/[ ? IDK any shell where this isn't implemented - I
always assumed it's a POSIX compatibility stopgap older systems needed
to stay compliant with their shipped shell.
It's required because it might be executed by non-shell programs.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#ta…
My Mac even has /usr/bin/cd.
The "special builtins" which aren't required to exist as binaries are:
break : continue . eval exec exit export readonly return set shift
times trap unset
9:59 a.m.
New subject: Shell control through external commands
On Thu, 14 Jul 2016, Random832 wrote:
My Mac even has /usr/bin/cd.
After which, of course, the shell returns to where it was... Or does
it do a getcwd() after each command or something?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
10:09 a.m.
New subject: Shell control through external commands
On Thu, Jul 14, 2016, at 23:59, Dave Horsfall wrote:
On Thu, 14 Jul 2016, Random832 wrote:
The existence of cd as a real command is a bit silly (Ubuntu doesn't
seem to bother with it), but it is technically required by the standard.
My Mac even has /usr/bin/cd.
After which, of course, the shell returns to where it was... Or does
it do a getcwd() after each command or something? 
7:55 p.m.
New subject: Shell control through external commands
On 7/14/16 11:59 PM, Dave Horsfall wrote:
On Thu, 14 Jul 2016, Random832 wrote:
Consider something like `find . -type d -exec cd {} \;' to test for
directory search permission. That's the only use I've ever seen advocated.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
My Mac even has /usr/bin/cd.
After which, of course, the shell returns to where it was... Or does
it do a getcwd() after each command or something?
3081
days inactive
3083
days old
8 comments
6 participants
participants (6)
-
arnold＠skeeve.com -
Chet Ramey -
Dave Horsfall -
Random832 -
shawn wilson -
Steve Nickolas