Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug?
On Tue, Feb 25, 2014 at 02:00:49AM +0100, Ingo Schwarze wrote: Hi Fabian, Fabian Raetz wrote on Mon, Feb 24, 2014 at 10:59:34PM +0100: while calculating my phys. memory (mb) with the folllowing shellsript i get as a result -424. sysctl -n hw.physmem returns 3849830400 #!/bin/sh phys_mem_bytes=`sysctl -n hw.physmem` phys_mem_mb=`expr $phys_mem_bytes / 1024 / 1024` echo $phys_mem_mb -- so i tried expr 2147483647 / 2 which returns 1073741824 while expr 2147483648 / 2 returns -1073741824 ksh(1) states that expr does Integer arithmetic. So is this the expected behaviour or a bug? How strange, six replies but nobody answered your question... The above behaviour is required by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_01_02_01 Integer variables and constants, including the values of operands and option-arguments, used by the standard utilities listed in this volume of POSIX.1-2008 shall be implemented as equivalent to the ISO C standard signed long data type; floating point shall be implemented as equivalent to the ISO C standard double type. Conversions between types shall be as described in the ISO C standard. All variables shall be initialized to zero if they are not otherwise assigned by the input to the application. Arithmetic operators and control flow keywords shall be implemented as equivalent to those in the cited ISO C standard section, as listed in Selected ISO C Standard Operators and Control Flow Keywords. So, POSIX *requires* that the output of expr 2147483648 + 0 and sh -c 'echo $((2147483648 + 0))' be machine dependent. For example, on i386, where long is 32 bit, it must be negative, but on amd64, where long is 64 bit, it must be positive. I guess it was a bad idea to have the standard require such weirdness; then again, this isn't exactly the only place where POSIX requires, well, weird behaviour. Hi, i should have included that i'm running amd64 and expr 2147483648 + 0 returns -2147483647 while sh -c 'echo $((2147483648 + 0))' returns 1073741824 as expected. This looks like expr is broken as Philip noted. I'm pretty new to shell programming and the behavior required by POSIX makes no sense to me at all how could i ever trust in expr with unknown numbers? For now, i will go with the perl based solution suggested by Stuart. Thanks to all, Fabian
Re: More OpenBSD on Hacker News -- RBAC and jails anyone?
previously on this list Matthew Weigel contributed: 1. Why doesn't OpenBSD have something like RBAC? RBAC has a lot more knobs to tweak, so you can always go back after a security incident and say aha! I need to tweak *that* knob to prevent this next time! But it has a steep learning curve, and everything you don't know about how your RBAC is configured is as much a problem as everything you got wrong. Most people use RBAC on Linux by turning it off. Though of course you also have to set the time aside for dealing with problems from updates that constantly appear on the Gentoo Hardened list though it does provide an extra layer easily for simple systems, like systrace and chflags can to lesser degrees but conversely might reduce the effectiveness of chflags due to the higher likelihood of a kernel exploit especially on those complex systems where a great deal needs to be allowed by the RBAC/MAC. You certainly have to spend a long time configuring linux (which is thankfully very configure outable) and writing and auditing a lot of code to get RBAC anywhere near as uncircumventable as chflags and even DACs on an OpenBSD kernel. Grsecurity is a bolt on and so has many addon features like chroot escape prevention techniques but obviously struggles with upstream to get at the real important core of Linux and certainly cannot change the mindset of Linux which is features trump almost everything. Just look at systemd overruling the more security conscious and those that have atleast some understanding of the lower levels of the OS. Whilst I say security vs functionality is a myth due to time and the right care working around it, in general and by default it is often true. One of OpenBSDs primary goals is just that and the users learn from that. It's like trying to add armor to a land rover or designing it as an armoured vehicle in the first place. OpenBSD permissions are fairly simple, thoroughly considered, and set up with sane defaults. Most people continue to rely on just these basic controls, on OpenBSD *and* on systems with RBAC. What I find amusing is just how often it isn't a defence in depth approach because the power of DACs and priviledge seperation are hardly used or even barely understood by RBAC advocates. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
ksh reopening stdin
Hi!
I'm doing this:
--- script.sh ---
#!/bin/ksh
for word in $(tr '\n' ' ');do
# ^^ tr(1) reads from standard input
... some stuff ...
done
read FOO
case ${FOO} in
... ... ...
esac
--- script.sh ---
$ script.sh /foo/bar
The problem with this of course, is that I want `read' to read from the
user interactively, also from stdin, but stdin is piped to the script
(and subsequently to tr(1)) before `read'. So now `read' just gets eof.
I'm thinking about something along the lines of first closing the
stdin that is piped to the script (somehow, I don't know), then
reopening it (also, somehow). I know this sounds vague, but does the
concept makes sense at all?
I was playing around with something like this:
for word in $(tr ..);do; ... ;done
exec 3/dev/stdin
exec -
exec 03
read FOO
Thanks for any pointers!
Daniel
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug?
On 02/25/2014 15:43, Fabian Raetz wrote: On Tue, Feb 25, 2014 at 02:00:49AM +0100, Ingo Schwarze wrote: Hi Fabian, Fabian Raetz wrote on Mon, Feb 24, 2014 at 10:59:34PM +0100: while calculating my phys. memory (mb) with the folllowing shellsript i get as a result -424. sysctl -n hw.physmem returns 3849830400 #!/bin/sh phys_mem_bytes=`sysctl -n hw.physmem` phys_mem_mb=`expr $phys_mem_bytes / 1024 / 1024` echo $phys_mem_mb -- so i tried expr 2147483647 / 2 which returns 1073741824 while expr 2147483648 / 2 returns -1073741824 ksh(1) states that expr does Integer arithmetic. So is this the expected behaviour or a bug? How strange, six replies but nobody answered your question... The above behaviour is required by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_01_02_01 Integer variables and constants, including the values of operands and option-arguments, used by the standard utilities listed in this volume of POSIX.1-2008 shall be implemented as equivalent to the ISO C standard signed long data type; floating point shall be implemented as equivalent to the ISO C standard double type. Conversions between types shall be as described in the ISO C standard. All variables shall be initialized to zero if they are not otherwise assigned by the input to the application. Arithmetic operators and control flow keywords shall be implemented as equivalent to those in the cited ISO C standard section, as listed in Selected ISO C Standard Operators and Control Flow Keywords. So, POSIX *requires* that the output of expr 2147483648 + 0 and sh -c 'echo $((2147483648 + 0))' be machine dependent. For example, on i386, where long is 32 bit, it must be negative, but on amd64, where long is 64 bit, it must be positive. I guess it was a bad idea to have the standard require such weirdness; then again, this isn't exactly the only place where POSIX requires, well, weird behaviour. Hi, i should have included that i'm running amd64 and expr 2147483648 + 0 returns -2147483647 while sh -c 'echo $((2147483648 + 0))' returns 1073741824 as expected. This looks like expr is broken as Philip noted. I'm pretty new to shell programming and the behavior required by POSIX makes no sense to me at all how could i ever trust in expr with unknown numbers? For now, i will go with the perl based solution suggested by Stuart. Thanks to all, Fabian Hi, on my i386 system: $expr 2147483648 + 0 -2147483648 $sh -c 'echo $((2147483648 + 0))' -2147483648 $bash -c 'echo $((2147483648 + 0))' 2147483648 $zsh -c 'echo $((2147483648 + 0))' 2147483648 bug in ksh? Alex
Re: ksh reopening stdin
LEVAI Daniel l...@ecentrum.hu writes:
Hi!
Hi Daniel,
I'm doing this:
--- script.sh ---
#!/bin/ksh
for word in $(tr '\n' ' ');do
# ^^ tr(1) reads from standard input
... some stuff ...
done
read FOO
case ${FOO} in
... ... ...
esac
--- script.sh ---
$ script.sh /foo/bar
The problem with this of course, is that I want `read' to read from the
user interactively, also from stdin, but stdin is piped to the script
(and subsequently to tr(1)) before `read'. So now `read' just gets eof.
I'm thinking about something along the lines of first closing the
stdin that is piped to the script (somehow, I don't know), then
reopening it (also, somehow). I know this sounds vague, but does the
concept makes sense at all?
I was playing around with something like this:
for word in $(tr ..);do; ... ;done
exec 3/dev/stdin
exec -
exec 03
read FOO
Try using ''read /dev/tty'' for your interactive user input.
Thanks for any pointers!
Daniel
--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ksh reopening stdin
On k, febr 25, 2014 at 14:19:44 +0100, Jérémie Courrèges-Anglas wrote: LEVAI Daniel l...@ecentrum.hu writes: Hi! Hi Daniel, [...] Try using ''read /dev/tty'' for your interactive user input. Cheers, Jérémie! I can even use `exec 0/dev/tty' before any read! Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug?
Hi, pae3 wrote on Tue, Feb 25, 2014 at 04:52:52PM +0400: on my i386 system: $expr 2147483648 + 0 -2147483648 $sh -c 'echo $((2147483648 + 0))' -2147483648 $bash -c 'echo $((2147483648 + 0))' 2147483648 $zsh -c 'echo $((2147483648 + 0))' 2147483648 bug in ksh? No. Assuming you are running on an ILP32 platform (for example, OpenBSD-i386), these are bugs in bash and zsh and should be fixed there, ksh is correct. Yours, Ingo
Re: ksh: expr 2147483648 / 2 = -1073741824 expected behavior or bug?
I'm pretty new to shell programming and the behavior required by POSIX makes no sense to me at all how could i ever trust in expr with unknown numbers? Indeed. Sometimes you just can't trust decisions set in stone by POSIX. Sometimes they are just plain broken. If an architecture with a strangely-sized long showed up, ksh would have to behave differently again. What are you going to do about it? Complain to the masterminds behind POSIX?
How to mount_udf -o rw ?
Dear OpenBSD misc listeners! How to mount UDF file systems on DVD-RAM media with read and write access? $ sudo disklabel cd0 # /dev/rcd0c: type: ATAPI disk: MEI_UDF label: fictitious duid: flags: bytes/sector: 2048 sectors/track: 100 tracks/cylinder: 1 sectors/cylinder: 100 cylinders: 22368 total sectors: 2236704 boundstart: 0 boundend: 2236704 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 22367040 UDF c: 22367040 UDF $ sudo mount_udf -o rw /dev/cd0a /mnt $ mount /dev/sd0a on / type ffs (local) /dev/sd0d on /home type ffs (local, nodev, nosuid, softdep) mfs:24322 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=8388608 512-blocks) /dev/sd1d on /usr type ffs (local, nodev, softdep) /dev/sd1e on /var type ffs (local, nodev, nosuid, softdep) /dev/cd0a on /mnt type udf (local, read-only) Best regards, Jens
Re: How to mount_udf -o rw ?
How to mount UDF file systems on DVD-RAM media with read and write access? You don't. Our ISOFS and UDF support is readonly.
Re: How to mount_udf -o rw ?
Theo de Raadt wrote: How to mount UDF file systems on DVD-RAM media with read and write access? You don't. Our ISOFS and UDF support is readonly. Thank you for confirmation! Sorry for the noise, only one look into the sources src/sbin/mount_udf/mount_udf.c would have been enough to answer the question myself ... With best regards, Jens
Re: How to mount_udf -o rw ?
On Wed, Feb 26, 2014 at 00:36, Jens A. Griepentrog wrote: Theo de Raadt wrote: How to mount UDF file systems on DVD-RAM media with read and write access? You don't. Our ISOFS and UDF support is readonly. Thank you for confirmation! Sorry for the noise, only one look into the sources src/sbin/mount_udf/mount_udf.c would have been enough to answer the question myself ... We should still document it, thanks for noticing. Fixed.
