Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #628816 > unrolled thread

Millisekunden

Back to article view | Back to ger.ct

Contents

  Millisekunden Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2024-10-21 19:13 +0200
    Re: Millisekunden Michael Bode <m.g.bode@web.de> - 2024-10-21 19:53 +0200
    Re: Millisekunden Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-21 17:58 +0000
      Re: Millisekunden Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> - 2024-10-21 21:47 +0200
      Re: Millisekunden "Wendelin Uez" <wuez@online.de> - 2024-10-22 10:58 +0200
        Re: Millisekunden Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-22 15:47 +0000
          Re: Millisekunden "Wendelin Uez" <wuez@online.de> - 2024-10-23 12:46 +0200
            Re: Millisekunden Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-23 22:24 +0000
              Re: Millisekunden Andreas Karrer <ak-4a@gmx.ch> - 2024-10-23 23:57 +0000
                Re: Millisekunden Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-24 07:25 +0000
                  Re: Millisekunden Andreas Karrer <ak-4a@gmx.ch> - 2024-10-24 10:05 +0000
              Re: Millisekunden "Wendelin Uez" <wuez@online.de> - 2024-10-25 12:28 +0200
                Re: Millisekunden Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-25 12:27 +0000
                Re: Millisekunden Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-10-25 15:00 +0200
    Re: Millisekunden Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-21 21:37 +0200
    Re: Millisekunden Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-22 17:05 +0200
    Re: Millisekunden Carla Schneider <carla_schn@proton.me> - 2024-10-24 09:16 +0200

#628816 — Millisekunden

Hallo,

ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen, vermisse
aber den Kontext, ob Amerikaner Amerikaner sind oder sich an Standards halten.
Und zwar, wenn ich das hier sehe:
64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
Sind das jetzt 1,195ms oder sind das 1195ms und der Amerikaner packt den Punkt
für die Tausender hin?
Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [next] | [standalone]

#628820

Christian Dürrhauer <cdurrhau@zedat.fu-berlin.de> writes:

> Hallo,
>
> ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen, vermisse
> aber den Kontext, ob Amerikaner Amerikaner sind oder sich an Standards halten.
> Und zwar, wenn ich das hier sehe:
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
> Sind das jetzt 1,195ms oder sind das 1195ms und der Amerikaner packt den Punkt
> für die Tausender hin?
> Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

Da da oben "64 bytes *from*" steht, kann man wohl davon ausgehen, dass
ping nicht lokalisiert ist.

[toc] | [prev] | [next] | [standalone]

#628823

On Mon, 21 Oct 2024 19:13:46 Christian Dürrhauer wrote:
> ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen,
> vermisse aber den Kontext, ob Amerikaner Amerikaner sind oder sich
> an Standards halten.  Und zwar, wenn ich das hier sehe:
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms

> Sind das jetzt 1,195ms oder sind das 1195ms und der Amerikaner
> packt den Punkt für die Tausender hin?

Ersteres. Du kannst das relativ einfach an der Zeit erkennen, die
zwischen dem Aufruf des Befehls und der Ausgabe der ersten Antwort
vergeht.

> Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

Was genau stört Dich daran eigentlich? Amerikaner würden für das
Tausender-Trennzeichen btw. ein Komma verwenden.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Wolke Nummer sieben zum verlieben. Mit Stefan. Ein eifriges Vergnügen!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#628825

On Oct 21, 2024 at 7:58:25 PM GMT+2, "Stefan Froehlich" <Stefan Froehlich>
wrote:

> Was genau stört Dich daran eigentlich? Amerikaner würden für das
> Tausender-Trennzeichen btw. ein Komma verwenden.

verflixt, dann habe ich das noch einmal verwechselt und mich selbst verwirrt.
Vielen Dank!


> Ersteres. Du kannst das relativ einfach an der Zeit erkennen, die
> zwischen dem Aufruf des Befehls und der Ausgabe der ersten Antwort
> vergeht.

ob das nun 1ms oder 1s ist, das kann ich nun wirklich nicht beurteilen, wenn
ich nicht davon ausgehen kann, dass es Echtzeit ist und schon eine Verzögerung
auftritt. Oder andersherum formuliert: wenn die 1ms erkennbar gewesen wäre und
hätte sein müssen, dann hätte ich nicht gefragt.

-- 
mit freundlichen Grüßen/with kind regards,

Christian Dürrhauer

[toc] | [prev] | [next] | [standalone]

#628828

> Was genau stört Dich daran eigentlich? Amerikaner würden für das
> Tausender-Trennzeichen btw. ein Komma verwenden.

Nur gibt die ermittelte Zeit nicht ein Amerikaner aus, sondern ein lokales 
Programm, welches mit großer Wahrscheinlichkeit unter Ländereinstellung 
deutsch läuft - es ist also von daher tatsächlich ungewiß, ob das ausgebende 
Programm es sich einfach macht und in nativem Format 1,234.567 ausgibt oder 
im länderspezifischen Format  1.234,567 (was für Nicht-Enduser-Anwendungen 
selten wäre). 

[toc] | [prev] | [next] | [standalone]

#628837

On Tue, 22 Oct 2024 10:58:18 Wendelin Uez wrote:
>> Was genau stört Dich daran eigentlich? Amerikaner würden für das
>> Tausender-Trennzeichen btw. ein Komma verwenden.

> Nur gibt die ermittelte Zeit nicht ein Amerikaner aus, sondern ein
> lokales Programm, welches mit großer Wahrscheinlichkeit unter
> Ländereinstellung deutsch läuft

Für wie groß hältst Du diese Wahrscheinlichkeit angesichts des
im Original zitierten Outputs:

#v+
64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
#v-

Gut, man könnte natürlich nur LC_NUMERIC auf deutsch stellen, aber
das passiert nicht, das tut man absichtlich (und stellt dann
hoffentlich nicht diese Frage).

> es ist also von daher tatsächlich ungewiß, ob das ausgebende
> Programm es sich einfach macht und in nativem Format 1,234.567
> ausgibt oder im länderspezifischen Format  1.234,567 (was für
> Nicht-Enduser-Anwendungen selten wäre). 

Tatsächlich macht ping es sich einfach und ist - wenigstens hier bei
mir - gar nicht lokalisierbar. Aber selbst wenn es das wäre: Siehe
oben.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan!? Ja! Denn betteln ist traumhafter als rubbeln.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#628884

>>> Was genau stört Dich daran eigentlich? Amerikaner würden für das
>>> Tausender-Trennzeichen btw. ein Komma verwenden.
>
>> Nur gibt die ermittelte Zeit nicht ein Amerikaner aus, sondern ein
>> lokales Programm, welches mit großer Wahrscheinlichkeit unter
>> Ländereinstellung deutsch läuft
>
> Für wie groß hältst Du diese Wahrscheinlichkeit angesichts des
> im Original zitierten Outputs:
>
> #v+
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
> #v-

Ich wollte damit klarstellen, es kommt nicht drauf an, welchen nationalen 
Ursprungs das Programm ist, sondern ob es lokalisiert ist. Der DIR-Befehl 
z.B. gibt die Dateigrößen in lokalisierter Form aus, d.h. mit Tausenderpunkt 
und nicht -komma, der TIME-Befehl  nutzt für die Dezimalen der Sekunden 
ebenfalls das Komma für die Nachkommastellen.

Aus deinem Beispiel kann man nicht schließen, ob die Ausgabe lokalisiert ist 
oder nicht, aber ich würde vermuten, daß es eins komma irgendwas mSek sind.


> Tatsächlich macht ping es sich einfach und ist - wenigstens hier bei
> mir - gar nicht lokalisierbar.

Normalerweise hat der User nur bei großeren Programmen wie z.B. 
Office-Paketen die Möglichkeit, die durch das OS vorgegebene Lokalsierung zu 
überschreiben, ansonsten entscheidet der Programmierer, wie die Ausgabe 
formatiert wird, eben entweder gar nicht (dann also enstprechend der Vorgabe 
des Entwicklerwerkzeugs, i.d.R. US/englisch) oder dynamisch nach 
OS-Lokalisierung.




  Stefan
>
> -- 
> http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
> Offizieller Erstbesucher(TM) von mmeike
>
> Stefan!? Ja! Denn betteln ist traumhafter als rubbeln.
> (Sloganizer) 

[toc] | [prev] | [next] | [standalone]

#628887

On Wed, 23 Oct 2024 12:46:28 Wendelin Uez wrote:
>>>> Was genau stört Dich daran eigentlich? Amerikaner würden für das
>>>> Tausender-Trennzeichen btw. ein Komma verwenden.

>>> Nur gibt die ermittelte Zeit nicht ein Amerikaner aus, sondern ein
>>> lokales Programm, welches mit großer Wahrscheinlichkeit unter
>>> Ländereinstellung deutsch läuft

>> Für wie groß hältst Du diese Wahrscheinlichkeit angesichts des
>> im Original zitierten Outputs:

>> #v+
>> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
>> #v-
 
> Ich wollte damit klarstellen, es kommt nicht drauf an, welchen
> nationalen Ursprungs das Programm ist, sondern ob es lokalisiert
> ist.

Ja, natürlich. Wäre das Programm lokalisiert und das locale
entsprechen eingestellt, stünde da aber nicht "from" sondern "von".
*Dann* könnte man auch über einen Tausenderpunkt nachdenken.

> Der DIR-Befehl z.B. gibt die Dateigrößen in lokalisierter
> Form aus, d.h. mit Tausenderpunkt und nicht -komma, der
> TIME-Befehl  nutzt für die Dezimalen der Sekunden 
> ebenfalls das Komma für die Nachkommastellen.

Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
geben hier jedenfalls gar keine Tausendertrenner aus:

#v+
$ ls -l /boot/
insgesamt 145261
-rw-r--r-- 1 root root   236382 16. Aug 2023  config-5.10.0-25-amd64
#v-

Aber das Programm ist ganz offenbar lokalisiert.

time(1) ist hingegen nicht lokalisiert und verwendet ausschließlich
den Punkt als Dezimaltrenner:

#v+
$ export LC_ALL=de_DE.utf-8
$ /usr/bin/time sleep 1
0.00user 0.00system 0:01.00elapsed 0%CPU (0avgtext+0avgdata 1928maxresident)k
0inputs+0outputs (0major+89minor)pagefaults 0swaps
#v-

Lediglich das bash-Builtin "time" verhält sich anders:

#v+
$ time sleep 1

real    0m1,001s
user    0m0,001s
sys     0m0,000s
#v-


> Aus deinem Beispiel kann man nicht schließen, ob die Ausgabe
> lokalisiert ist oder nicht, aber ich würde vermuten, daß es eins
> komma irgendwas mSek sind.

Es war nicht mein Beispiel, und der englische Text ist ein mehr als
starkes Indiz dafür, dass das Programm keine Lokalisierung beachtet.
 
> [...] ansonsten entscheidet der Programmierer, wie die Ausgabe
> formatiert wird, eben entweder gar nicht (dann also enstprechend
> der Vorgabe des Entwicklerwerkzeugs, i.d.R. US/englisch) oder
> dynamisch nach OS-Lokalisierung.

Im Fall von ping(8) eben immer US-amerikanisch.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Junge, Junge, was für ein Stuß!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#628889

* Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at>:
> On Wed, 23 Oct 2024 12:46:28 Wendelin Uez wrote:
>>>>> Was genau stört Dich daran eigentlich? Amerikaner würden für das
>>>>> Tausender-Trennzeichen btw. ein Komma verwenden.
>
>> Der DIR-Befehl z.B. gibt die Dateigrößen in lokalisierter
>> Form aus, d.h. mit Tausenderpunkt und nicht -komma, der
>> TIME-Befehl  nutzt für die Dezimalen der Sekunden 
>> ebenfalls das Komma für die Nachkommastellen.
>
> Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
> geben hier jedenfalls gar keine Tausendertrenner aus:
>
> #v+
> $ ls -l /boot/
> insgesamt 145261
> -rw-r--r-- 1 root root   236382 16. Aug 2023  config-5.10.0-25-amd64
> #v-

#v+
$ for loc in C en_US.utf8 de_DE.utf8 de_CH.utf8; do LC_NUMERIC=$loc ls -lg --block-size=\'1 tst; done
-rw-r--r-- 1 root 1755329 Oct 24 01:36 tst
-rw-r--r-- 1 root 1,755,329 Oct 24 01:36 tst
-rw-r--r-- 1 root 1.755.329 Oct 24 01:36 tst
-rw-r--r-- 1 root 1’755’329 Oct 24 01:36 tst
#v-


Wo das mit dem Apostroph dokumentiert ist, weiss ich auch nicht.

 - Andi

[toc] | [prev] | [next] | [standalone]

#628892

On Thu, 24 Oct 2024 01:57:27 Andreas Karrer wrote:
> * Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at>:
>> Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
>> geben hier jedenfalls gar keine Tausendertrenner aus:

>> #v+
>> $ ls -l /boot/
>> insgesamt 145261
>> -rw-r--r-- 1 root root   236382 16. Aug 2023  config-5.10.0-25-amd64
>> #v-

> #v+
> $ for loc in C en_US.utf8 de_DE.utf8 de_CH.utf8; do LC_NUMERIC=$loc ls -lg --block-size=\'1 tst; done
> -rw-r--r-- 1 root 1755329 Oct 24 01:36 tst
> -rw-r--r-- 1 root 1,755,329 Oct 24 01:36 tst
> -rw-r--r-- 1 root 1.755.329 Oct 24 01:36 tst
> -rw-r--r-- 1 root 1’755’329 Oct 24 01:36 tst
> #v-

> Wo das mit dem Apostroph dokumentiert ist, weiss ich auch nicht.

Woher wusstest Du dann, dass das überhaupt möglich ist?

Mit etwas Suchen habe ich es in der GNU-Dokumentation gefunden:
<https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html>.
Ohne es gezielt zu suchen, hat man da eher wenig Chancen, der
einzige Link dorthin bei ls versteckt sich in der Option
--kibibytes.

Wie auch immer, jetzt bin ich nur noch mehr verwirrt, denn der erste
Server, auf dem ich das versucht habe, gab mir als Antwort:

#v+
$ for loc in C en_US.utf8 de_DE.utf8 de_CH.utf8; do LC_NUMERIC=$loc ls -lg --block-size=\'1 /boot/initrd.img-6.1.0-26-amd64; done
-rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
-rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
-rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
-rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
$ locale -a|grep de_.*utf8
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_IT.utf8
de_LI.utf8
de_LU.utf8
#v-

Gut, auf allen wurde dann korrekt lokalisiert, aber was hat diese
eine Maschine für ein Problem? "Identifies itself as Swiss"?

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die vollendetste Steigerungsform von breit!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#628906

* Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at>:
> On Thu, 24 Oct 2024 01:57:27 Andreas Karrer wrote:
>> * Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at>:
>>> Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
>>> geben hier jedenfalls gar keine Tausendertrenner aus:
>
>>> #v+
>>> $ ls -l /boot/
>>> insgesamt 145261
>>> -rw-r--r-- 1 root root   236382 16. Aug 2023  config-5.10.0-25-amd64
>>> #v-
>
>> #v+
>> $ for loc in C en_US.utf8 de_DE.utf8 de_CH.utf8; do LC_NUMERIC=$loc ls -lg --block-size=\'1 tst; done
>> -rw-r--r-- 1 root 1755329 Oct 24 01:36 tst
>> -rw-r--r-- 1 root 1,755,329 Oct 24 01:36 tst
>> -rw-r--r-- 1 root 1.755.329 Oct 24 01:36 tst
>> -rw-r--r-- 1 root 1’755’329 Oct 24 01:36 tst
>> #v-
>
>> Wo das mit dem Apostroph dokumentiert ist, weiss ich auch nicht.
>
> Woher wusstest Du dann, dass das überhaupt möglich ist?

Irgendwann vor Jahren in einem Posting aufgeschnappt, in mein "l"-Alias
reingeschrieben und dann sofort vergessen.

> Mit etwas Suchen habe ich es in der GNU-Dokumentation gefunden:
><https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html>.
> Ohne es gezielt zu suchen, hat man da eher wenig Chancen, der
> einzige Link dorthin bei ls versteckt sich in der Option
> --kibibytes.
>
> Wie auch immer, jetzt bin ich nur noch mehr verwirrt, denn der erste
> Server, auf dem ich das versucht habe, gab mir als Antwort:
>
> #v+
> $ for loc in C en_US.utf8 de_DE.utf8 de_CH.utf8; do LC_NUMERIC=$loc ls -lg --block-size=\'1 /boot/initrd.img-6.1.0-26-amd64; done
> -rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
> -rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
> -rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
> -rw-r--r-- 1 root 44’490’046 Okt  3 23:13 /boot/initrd.img-6.1.0-26-amd64
> $ locale -a|grep de_.*utf8
> de_AT.utf8
> de_BE.utf8
> de_CH.utf8
> de_DE.utf8
> de_IT.utf8
> de_LI.utf8
> de_LU.utf8
> #v-
>
> Gut, auf allen wurde dann korrekt lokalisiert, aber was hat diese
> eine Maschine für ein Problem? "Identifies itself as Swiss"?

Faszinierend.

Für das locale "C" sollten keine Tausernderternnzeichen ausgegeben
werden. Ist dein ls ein alias? Mal mit "/bin/ls -lg --block-size...."
versuchen.

 - Andi

[toc] | [prev] | [next] | [standalone]

#628966

> Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
> geben hier jedenfalls gar keine Tausendertrenner aus:

Bei fehlender OS-Angabe sollte man nicht von einem Nischenprodukt als 
Default ausgehen :-) 

[toc] | [prev] | [next] | [standalone]

#628973

On Fri, 25 Oct 2024 12:28:09 Wendelin Uez wrote:
>> Mir ist unklar, was Du mit dem DIR-Befehl meinst. dir(1) bzw. ls(1)
>> geben hier jedenfalls gar keine Tausendertrenner aus:

> Bei fehlender OS-Angabe sollte man nicht von einem Nischenprodukt
> als Default ausgehen :-) 

Bei einem (deutsch) lokalisierten Windows sieht die Ausgabe von PING
aber definitiv anders als im Originalposting aus. Das kommt also
schon einmal nicht in Frage. Nebstbei: Wer schreibt unter Windows
heutzutage Befehle in Blockbochstaben?

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für mächtige Zecher, gegen den Frust!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#628975

Wendelin Uez meinte:

> Bei fehlender OS-Angabe sollte man nicht von einem Nischenprodukt als
> Default ausgehen :-)

Und bei vorhandener OS-Angabe sollte man nicht von einer anderen Annahme 
ausgehen. Aus der ursprünglichen Frage zitiere ich mal:

| Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.
-- 
 gpg-Key (DSA 1024) D36AD663E6DB91A4
 fingerprint = 2983 4D54 E00B 8483 B5B8  C7D1 D36A D663 E6DB 91A4
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#628824

Am 21.10.2024 um 19:13 schrieb Christian Dürrhauer:
> Hallo,
> 
> ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen, vermisse
> aber den Kontext, ob Amerikaner Amerikaner sind oder sich an Standards halten.
> Und zwar, wenn ich das hier sehe:
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
> Sind das jetzt 1,195ms oder sind das 1195ms und der Amerikaner packt den Punkt
> für die Tausender hin?
> Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

1,xms sinds. Aber das ist doch im LAN, oder ?

[toc] | [prev] | [next] | [standalone]

#628836

Am 21.10.24 um 19:13 schrieb Christian Dürrhauer:

> ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen, vermisse
> aber den Kontext, ob Amerikaner Amerikaner sind oder sich an Standards halten.
> Und zwar, wenn ich das hier sehe:
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
> Sind das jetzt 1,195ms oder sind 

In welche Programmiersprache wird ',' bei Gleitkomma verwendet?

IP 1921681254 würde Verwirrung stiften.
> Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

Und erst FORTRAN.

[toc] | [prev] | [next] | [standalone]

#628891

Christian Dürrhauer wrote:
> 
> Hallo,
> 
> ich bin verwirrt. Zwar bin ich in der Lage, eine Einheit zu lesen, vermisse
> aber den Kontext, ob Amerikaner Amerikaner sind oder sich an Standards halten.
> Und zwar, wenn ich das hier sehe:
> 64 bytes from 192.168.1.254: icmp_seq=1460 ttl=64 time=1.195 ms
> Sind das jetzt 1,195ms oder sind das 1195ms und der Amerikaner packt den Punkt
> für die Tausender hin?

Der Amerikaner verwendet gar keinen Punkt fuer die Tausender sondern ein Komma,
der Punkt ist der Dezimalpunkt. Im uebrigen waere eine Sekunde Ping in einem lokalen
Netz absurd langsam.

> Kommt von einem macOS, aber bei Linux ist's keinen Deut besser.

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web