QuoteBareword "_" not allowed while "strict subs" in use at C:/Strawberry/perl/site/lib/Archive/Zip/DirectoryMember.pm line 31.
Quoteheißt, es könnte sein, dass die 5.26.1 das schon nicht mehr zulässt? Kann ich das in einer Liste irgend wo finden, ob und in welchen Versionen das geht?This limitation might be removed in a future version of perl.
QuoteLimitation with regard to _
...
1 2 3 4 5
if (-e $path) { if (-w _) { # Hier wird die Schreibbarkeit von $path bewertet ...; } }
1 2 3 4 5 6
if (-e $fileName) { # -e does NOT do a full stat, so we need to do one now if (-d _ ) { my @stat = stat(_); ...
QuoteC:\>perl -w -E -Mstrict "say -e _"
Useless use of a constant ("-Mstrict") in void context at -e line 1.
C:\>perl -w -MArchive::Zip::DirectoryMember -E 1
C:\>
QuoteSummary of my perl5 (revision 5 version 26 subversion 1) configuration:
Platform:
osname=MSWin32
osvers=6.3
archname=MSWin32-x64-multi-thread
uname='Win32 strawberry-perl 5.26.1.1 #1 Sun Sep 24 05:32:33 2017 x64'
config_args='undef'
hint=recommended
useposix=true
d_sigaction=undef
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='gcc'
ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields'
optimize='-s -O2'
cppflags='-DWIN32'
ccversion=''
gccversion='7.1.0'
gccosandvers=''
intsize=4
longsize=4
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='long long'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='g++'
ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\x86_64-w64-mingw32\lib C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\7.1.0
libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
libc=
so=dll
useshrplib=true
libperl=libperl526.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs
dlext=xs.dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
HAVE_INTERP_INTERN
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
Built under MSWin32
Compiled at Sep 24 2017 05:47:34
@INC:
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
2020-12-26T14:00:02 biancaMein Fehler... gemeint war: perl -w -Mstrict -E "say -e _". Sorry.Hier die Ergebnisse:
QuoteC:\>perl -w -E -Mstrict "say -e _"
Useless use of a constant ("-Mstrict") in void context at -e line 1.
2020-12-26T14:00:02 biancaWenn das fehlerfrei durchläuft, dann findet Perl keinen Syntaxfehler, wenn das Modul für sich alleine übersetzt wird (und der erste Test sollte dann auch keine weiteren Erkenntnisse bringen).C:\>perl -w -MArchive::Zip::DirectoryMember -E 1
2020-12-26T14:00:02 biancaPerl Version:QuoteSummary of my perl5 (revision 5 version 26 subversion 1) configuration:
2020-12-26T16:43:59 hajMein Fehler... gemeint war: perl -w -Mstrict -E "say -e _". Sorry.
QuoteD:\>perl -w -Mstrict -E "say -e _"
Use of uninitialized value in say at -e line 1.
2020-12-26T16:43:59 hajWas passiert bei perl -wc D:ein\programm (bitte den Pfad zu Deinem Programm einsetzen)? Falls Du Module mit require einbindest, hilft das nicht unbedingt weiter, aber vielleicht tritt der Fehler da schon auf.
2020-12-26T16:43:59 hajJa das hatte ich zwischenzeitlich eingebaut und dann lief es auch durch. Im übrigen mache ich es so in eigenen Programmen immer. _ kannte ich gar nicht. Spart man damit wirklich so viel ein, dass das heutzutage noch nennenswert ist?Was passiert, wenn Du in der Zeile 31 in C:/Strawberry/perl/site/lib/Archive/Zip/DirectoryMember.pm das _ durch $fileName ersetzt? Vielleicht kitzelt das eine andere Fehlermeldung raus, die der Ursache näher kommt.
1 2 3 4 5 6 7
if (-e $fileName) { # -e does NOT do a full stat, so we need to do one now # if (-d _ ) { if (-d $fileName) { # my @stat = stat(_); my @stat = stat($fileName);
2020-12-26T17:59:04 bianca2020-12-26T16:43:59 hajWas passiert bei perl -wc D:ein\programm (bitte den Pfad zu Deinem Programm einsetzen)? Falls Du Module mit require einbindest, hilft das nicht unbedingt weiter, aber vielleicht tritt der Fehler da schon auf.
-c nutze ich immer und -w entspricht ja warnings, was auch überall drin ist. Module werden immer require't, nicht ge-use-t.
2020-12-26T17:59:04 bianca2020-12-26T16:43:59 hajJa das hatte ich zwischenzeitlich eingebaut und dann lief es auch durch.Was passiert, wenn Du in der Zeile 31 in C:/Strawberry/perl/site/lib/Archive/Zip/DirectoryMember.pm das _ durch $fileName ersetzt? Vielleicht kitzelt das eine andere Fehlermeldung raus, die der Ursache näher kommt.
Im übrigen mache ich es so in eigenen Programmen immer. _ kannte ich gar nicht. Spart man damit wirklich so viel ein, dass das heutzutage noch nennenswert ist?
2020-12-26T17:59:04 biancaAuf jeden Fall ist das nicht schön, weil ich das ja nicht bei jedem Update wieder neu machen will.
2020-12-26T17:59:04 biancaEs wirft also den Fehler nur zur Ausführungszeit, nicht zur Compilierzeit. Was kann das sein?
@geht's_noch = stat(_);
2020-12-26T22:56:18 hajInteressant wäre die Stellen, bevor und nachdem Du Archive::Zip einbindest.
2020-12-26T22:56:18 hajInteressant wäre die Stellen, bevor und nachdem Du Archive::Zip einbindest.
1 2 3 4 5 6 7 8
#!/usr/bin/perl use strict; use warnings; use 5.010; say "vorher: '"._."'"; require Archive::Zip; say "nachher: '"._."'";
QuoteBareword "_" not allowed while "strict subs" in use at test.pl line 6.
Bareword "_" not allowed while "strict subs" in use at test.pl line 8.
Execution of test.pl aborted due to compilation errors.
1 2 3 4 5 6 7 8
#!/usr/bin/perl use strict; use warnings; use 5.010; say "vorher: '"._."'"; use Archive::Zip; say "nachher: '"._."'";
QuoteAlso ist use auch keine Lösung.Bareword "_" not allowed while "strict subs" in use at test.pl line 6.
BEGIN not safe after errors--compilation aborted at test.pl line 7.
2020-12-27T09:05:08 biancaMit Deinem Code bekomme ich auch die Meldung. Aber "vorher: '"._."'" ist auch etwas anderes als -e _ oder stat (_).Ist das Verhalten bei dir/euch anders?
2020-12-27T09:05:08 biancaSo eine Meldung zu unterdrücken ist keine gute Idee. Du kannst Dir den Code vonGibt es denn für strict einen Schalter, der genau diese Meldung unterdrückt? Würde das Programm ohne die Abbruchmeldung so arbeiten als wäre mit _ alles gut? Ist das vielleicht nur eine "falsche" Meldung? Wie könnte man denn testen, ob es ohne Meldung "korrekt" arbeiten würde? Wenn der Cache leer ist, veranlasst _ dann zu einem stat() oder was anderes oder gar nichts?
1 2 3 4 5 6
if (-e $fileName) { # -e does NOT do a full stat, so we need to do one now if (-d _ ) { # Das bleibt hier so stehen! # my @stat = stat(_); my @stat = stat($fileName);
2020-12-27T11:29:25 hajIst drin. Sobald der Job gelaufen ist melde ich mich. Kann morgen werden.Aber ich habe eine Spur. Dazu wäre es doch noch nötig, die Ersetzung von _ durch $fileName nur an der Stelle vorzunehmen, an der Perl sich beschwert hat:
2020-12-27T11:29:25 hajDurch meinen eigenen Code sicher nicht aber durch ein anderes CPAN Modul - was davor läuft - schon eher.Irgendein Teil in Deinem Code übernagelt die stat-Funktion.
QuoteKann man das denn nicht feststellen, wenn da was überschrieben wird?Bareword "_" not allowed while "strict subs" in use at C:/Strawberry/perl/site/lib/Image/ExifTool.pm line 2422.
BEGIN not safe after errors--compilation aborted at C:/Strawberry/perl/site/lib/Image/ExifTool.pm line 4530.
2020-12-27T11:29:25 hajDas scheidet als Lösung eigentlich aus. Das ist nicht nur ein kleines Script sondern mein Intranet mit zig Jobs und zig CPAN Modulen, was alles ineinander greift. Ich sehe die Ursache des Problems bis jetzt auch nicht in require an sich. Oder wird es allgemein als best practice angesehen, Systemkommandos zu überschreiben mit dem Motto "ist kein Problem weil nur begrenzte Wirkung wenn jeder use anstatt require verwendet"?In diesem Fall kannst Du Dir behelfen, indem Du use Archive::Zip möglichst früh (und wirklich mit use und nicht mit require) einbindest.
2020-12-28T08:52:06 biancaDas vermute ich auch.2020-12-27T11:29:25 hajDurch meinen eigenen Code sicher nicht aber durch ein anderes CPAN Modul - was davor läuft - schon eher.Irgendein Teil in Deinem Code übernagelt die stat-Funktion.
2020-12-28T08:52:06 biancaDas fängst Du Dir mit require ein, dass je nach Aufrufreihenfolge der erste Modul, der drankommt, drüberfällt.Heute macht auch Image::ExifTool Ärger:QuoteKann man das denn nicht feststellen, wenn da was überschrieben wird?Bareword "_" not allowed while "strict subs" in use at C:/Strawberry/perl/site/lib/Image/ExifTool.pm line 2422.
BEGIN not safe after errors--compilation aborted at C:/Strawberry/perl/site/lib/Image/ExifTool.pm line 4530.
1 2 3 4 5 6
use Sub::Util; use Variable::Magic qw<wizard cast>; my $wiz = wizard (set => sub { print "stat ist nun ", Sub::Util::subname(\&CORE::GLOBAL::stat), "\n" }); cast *CORE::GLOBAL::stat,$wiz;
2020-12-28T08:52:06 biancaDas Problem bei require ist, dass es erst zur Laufzeit stattfindet. Dadurch wird die Fehlersuche schwieriger, weil alle möglichen Komponenten irgendwo was rumdoktorn können. Ich vermute, ein Autor eines der der zig Module meinte tatsächlich, da etwas Gutes zu tun und hat nicht ausreichend getestet. Dein Intranet läuft ja anscheinend unter Windows? Hintergrund: stat kann unter Windows systembedingt nicht das gleiche tun wie unter Linux, vielleicht hat da ein Modul schlampig verschlimmbessert.2020-12-27T11:29:25 hajDas scheidet als Lösung eigentlich aus. Das ist nicht nur ein kleines Script sondern mein Intranet mit zig Jobs und zig CPAN Modulen, was alles ineinander greift. Ich sehe die Ursache des Problems bis jetzt auch nicht in require an sich. Oder wird es allgemein als best practice angesehen, Systemkommandos zu überschreiben mit dem Motto "ist kein Problem weil nur begrenzte Wirkung wenn jeder use anstatt require verwendet"?In diesem Fall kannst Du Dir behelfen, indem Du use Archive::Zip möglichst früh (und wirklich mit use und nicht mit require) einbindest.
2020-12-28T08:52:06 biancaWeil stat eine eingebaute Funktion ist. Die kann man auch gar nicht so einfach überschreiben. Wenn Du in einem Modul ein sub stat { ...; } definierst und dann stat aufrufst, wird trotzdem die eingebaute Funktion verwendet.Wieso kommt denn da eigentlich nicht diese ...sub redefined... Meldung, wenn etwas etwas anderes überschreibt?
2020-12-28T08:52:06 biancaGern geschehen. Im Lockdown hat man eh' nicht viel anderes zu tun :)Zwischendurch auch vielen vielen Dank für deine Hilfe, haj!
Und auch allen anderen Mitlesern!
2020-12-28T23:37:48 CrianÄhm ja, der Link auf Deine Perl-Seite gibt dafür einige Indizien :)Ich hab schon lange nichts mehr aktiv mit Perl programmiert, ...
2020-12-28T23:37:48 Crianaber damals hab ich mir für mich aus irgendeinem Grund gemerkt, use zu benutzen und nicht require.
Das klingt danach, als wäre das bei dir eine riesige Umstellung und würde wohl auch gar nicht das Problem beheben, aber hat jemand die ganzen Unterschiede dessen parat?
BEGIN { require Module; Module->import; }
2020-12-29T10:42:42 hajWenn ein Programm je nach Input ganz verschiedene Pfade durchläuft, die ganz unterschiedliche Module benötigen und die Dauer der Übersetzung der Module ein Problem darstellt: Deswegen findet man das in "älteren" CGI-Programmen ohne persisenten Perl-Interpreter. Die laden dann für jeden Request nur die für diesen Request nötigen Module und sterben nach der Abarbeitung.
2021-01-02T10:53:58 hajDer Fehler dürfte also bei Dir gar nicht auftreten und Du kannst das Modul einfach rauswerfen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
#!/usr/bin/perl use strict; use warnings; use 5.010; #use Win32::UTCFileTime qw(:globally); system 'cls'; my @files = ( 'xyz', # vom 15.08. also mit Sommerzeit richtig ist 19:14 'abc', # vom 16.12. also ohne Sommerzeit richtig ist 12:42 ); schleife(\@files); sub schleife { my ($files) = @_; foreach my $datei (@$files) { say "Datei '$datei'"; my @epoch = localtime((stat($datei))[9]); $epoch[4] ++; $epoch[5] += 1900; say sprintf("%02d.%02d.%04d %02d:%02d:%02d",@epoch[3..5],reverse((@epoch)[0..2]))."\n"; } }
2021-01-03T12:19:36 bianca2021-01-02T10:53:58 hajDer Fehler dürfte also bei Dir gar nicht auftreten und Du kannst das Modul einfach rauswerfen.
Das kann ich leider nicht bestätigen. Hier liefert Perl in stat()[9] nur Uhrzeiten, die die Sommerzeit nicht berücksichtigen, also innerhalb der Sommerzeit falsch sind.
2021-01-03T12:19:36 biancaWenn ich Win32::UTCFileTime aktiviere kommt richtig 19:14 raus.
Die untere Datei kommt in beiden Fällen richtig mit 12:42 raus.
Wie kriege ich denn jetzt richtige Sommerzeiten und keine Unterstrichfehlermeldung hin?
2021-01-03T12:19:36 biancaUnd wie deckt sich das, dass man Win32::UTCFileTime eigentlich nicht mehr brauchen sollte?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
#!/usr/bin/perl use strict; use warnings; use 5.010; #use Win32::UTCFileTime qw(:globally); require Date::Calc; # Date::Calc ist eh systemweit eingebunden #system 'cls'; my @files = ( 'xyz', # vom 15.08. also mit Sommerzeit richtig ist 19:14 'abc', # vom 16.12. also ohne Sommerzeit richtig ist 12:42 ); schleife(\@files); sub schleife { my ($files) = @_; foreach my $datei (@$files) { say "Datei '$datei'"; my $stat9 = (stat($datei))[9]; # Perl's localtime my @epoch = localtime $stat9; $epoch[4] ++; $epoch[5] += 1900; say sprintf( "$stat9 --> %02d.%02d.%04d %02d:%02d:%02d", @epoch[3..5], reverse(@epoch[0..2]) ); # Date::Calc @epoch = Date::Calc::Localtime($stat9); # liefert Jahr,Monat,Tag,Stunde,Minute,Sekunde,DayOfYear,DayOfWeek,SommerzeitKNZ say sprintf( "Date::Calc --> %02d.%02d.%04d %02d:%02d:%02d KNZ: $epoch[8]", reverse(@epoch[0..2]), @epoch[3..5] ); # Sommerzeitkorrektur if ($^O =~ /mswin/i && $epoch[8] == 1) { @epoch = Date::Calc::Add_Delta_DHMS(@epoch[0..5],0,1,0,0); # 1 Stunde addieren say sprintf( "korrigiert --> %02d.%02d.%04d %02d:%02d:%02d", reverse(@epoch[0..2]), @epoch[3..5] ); } say "\n"; } }
Guest raubtier (logged out)Meine Frage wäre jetzt, ob dein Würg-Around (ich mag solche Wörter normalerweise nicht, aber das hier ist ja echt zum kotzen!) auch immer korrekt arbeitet. Probiere ihn auch mal mit Dateien aus, die am Tag der Zeitumstellung zwischen 1 und 4 Uhr erzeugt wurden, also z.B. um 01:30, 02:30 und 03:30. Teste dies sowohl am Tag der Umstellung auf Sommerzeit als auch am Tag der Umstellung auf Winterzeit.
Guest raubtier (logged out)Warum brauchst du Dateizeiten überhaupt? Außer für sowas wie rsync verlasse ich mich lieber nicht auf Zeitstempel.
Guest raubtier (logged out)Es muss nur jemand Dateien hin- und herkopieren und schon sind die Zeitstempel anders.
Guest raubtier (logged out)PS: Kann mal jemand ein nicht-warnendes Zertifikat für perl-community erstellen?
2021-01-04T22:12:03 RaubtierEs geht nicht darum, die Fähigkeiten von Date::Calc anzuzweifeln.
Es geht darum, dass es ja, wenn du die Zeit zurückstellst, 2x dieselbe Zeit hast, einmal mit DST und einmal ohne.
2021-01-04T08:32:06 biancaWürde mir Sicherheit geben, wenn du/ihr mal drauf schaut und mir deine/eure Meinung sag(s)t. Danach wäre das dann auch vorerst mal gelöst (umgangen, verbastelt wie auch immer).
1 2 3 4 5 6
my @epoch = localtime $stat9; .... if ($^O =~ /mswin/i && $epoch[8] == 1) { @epoch = Date::Calc::Add_Delta_DHMS(@epoch[0..5],0,1,0,0); ...;
2021-01-04T20:40:07 hajIch kann mal zur Zeitumstellung eine Testreihe ansetzen mit Win10 und Strawberry 5.30 oder 5.32, bei der ich weiß, was richtig ist und danach auch beurteilen kann, welche Komponente was falsch oder richtig macht.
2021-01-04T20:40:07 hajZuerst wandelst Du das stat-Ergebnis in localtime. Das sollte schon eine Sommerzeit-Korrektur anhand der auf dem System eingestellten (!) Zeitzone erledigen.
[*] Dann addierst Du nochmal genau eine Stunde, wenn das Datum in die Sommerzeit fiel, wohl in der Annahme, das Ergebnis von [c]stat[/c] sei in diesem Fall fehlerhaft. Warum addierst Du dann so kompliziert im "ausformulierten" Datum und nicht gleich bei [c]$stat9[/c]?
2021-01-04T20:40:07 hajDas Element $epoch[8] ist laut Dokumentation als "true" definiert und nicht als exakt 1. Ein sicherer Vergleich wäre if ($^O =~ /mswin/i && $epoch[8])
2021-01-04T20:40:07 hajAuch dann erscheint mir das $^O =~ /mswin/i recht fragil, nachdem es nicht klar ist, ob es wirklich am Betriebssystem oder an der C-Library hängt.[/list]
2021-01-04T20:40:07 hajMuss es denn wirklich und unbedingt lokale Zeit sein? Die nicht eindeutig: Es gibt in der Umstellungsnacht im Herbst für zwei stat-Resultate die gleiche lokale Zeit.
2021-01-04T21:15:56 bianca2021-01-04T20:40:07 hajZuerst wandelst Du das stat-Ergebnis in localtime. Das sollte schon eine Sommerzeit-Korrektur anhand der auf dem System eingestellten (!) Zeitzone erledigen.
Dann addierst Du nochmal genau eine Stunde, wenn das Datum in die Sommerzeit fiel, wohl in der Annahme, das Ergebnis von stat sei in diesem Fall fehlerhaft. Warum addierst Du dann so kompliziert im "ausformulierten" Datum und nicht gleich bei $stat9?
Das ist doch nur das Testscript für hier.
2021-01-04T21:15:56 biancaLaut Dokumentation:2021-01-04T20:40:07 hajEs gibt auch -1 und darauf darf es genau nicht matchen.Das Element $epoch[8] ist laut Dokumentation als "true" definiert und nicht als exakt 1. Ein sicherer Vergleich wäre if ($^O =~ /mswin/i && $epoch[8])
Quote-1 ist "true" bei Perl. Wenn Du -1 von 1 unterscheiden musst, dann ist das Glücksspiel. In welcher Situation bekommst Du -1?$isdst is true if the specified time occurs during Daylight Saving Time, false otherwise.
2021-01-04T21:15:56 biancaDas glaube ich Dir. Aber ich glaube nicht, dass der Fehler mit jeder C-Library auf Windows auftritt. Visual Studio 2013 verhält sich anders als Visual Studio 2015, und beides ist mswin. Zu mingw32, da ist $^O auch mswin, habe ich keine verlässlichen Daten.2021-01-04T20:40:07 hajAuch dann erscheint mir das $^O =~ /mswin/i recht fragil, nachdem es nicht klar ist, ob es wirklich am Betriebssystem oder an der C-Library hängt.
Bin mir 100 % sicher, dass es nur auf Win ist.
2021-01-04T21:15:56 biancaIn der Umstellungsnacht wird die lokale Zeit um eine Stunde zurückgedreht. stat liefert, wenn's korrekt implementiert ist, die Anzahl an Sekunden seit 1. Januar 1970 UTC, und läuft einfach weiter. Lokale Zeiten von 02:00 bis 03:00 gibt es in der Umstellungsnacht zweimal, die sind 3600 stat-Sekunden auseinander. Wenn Du also erst aus den stat-Resultaten lokale Zeiten ermittelst und dann hinterher anhand von $isdst "korrigierst", dann nenne ich das "von hinten durch die Brust ins Auge". Vergleiche kannst Du doch viel einfacher mit den stat-Resultaten machen!2021-01-04T20:40:07 hajMuss es denn wirklich und unbedingt lokale Zeit sein? Die nicht eindeutig: Es gibt in der Umstellungsnacht im Herbst für zwei stat-Resultate die gleiche lokale Zeit.
Das verstehe ich nicht. Was bedeutet das?
2021-01-05T01:18:37 hajUm uns zu verwirren?
2021-01-05T01:18:37 hajDu machst damit unentscheidbar, ob der vermutete Fehler in der stat-Implementierung, in der localtime-Implementierung oder in der Zeitzonen-Einstellung Deines Servers ist.
2021-01-05T01:18:37 hajLaut Dokumentation:
Quote-1 ist "true" bei Perl. Wenn Du -1 von 1 unterscheiden musst, dann ist das Glücksspiel. In welcher Situation bekommst Du -1?$isdst is true if the specified time occurs during Daylight Saving Time, false otherwise.
QuoteThe daylight savings time flag ("$dst") will be "-1" if this information is not available on your system, "0" for no daylight savings time (i.e., winter time) and "1" when daylight savings time is in effect.
2021-01-05T01:18:37 hajAuch dann erscheint mir das $^O =~ /mswin/i recht fragil, nachdem es nicht klar ist, ob es wirklich am Betriebssystem oder an der C-Library hängt.
2021-01-05T01:18:37 hajIn der Umstellungsnacht wird die lokale Zeit um eine Stunde zurückgedreht. stat liefert, wenn's korrekt implementiert ist, die Anzahl an Sekunden seit 1. Januar 1970 UTC, und läuft einfach weiter. Lokale Zeiten von 02:00 bis 03:00 gibt es in der Umstellungsnacht zweimal, die sind 3600 stat-Sekunden auseinander.
2021-01-05T01:18:37 hajVergleiche kannst Du doch viel einfacher mit den stat-Resultaten machen!
2021-01-05T08:42:41 biancaEher Unverständnis. Im Labor bemühe ich mich, Fehler zu isolieren und Experimente nachvollziehbar zu machen. Das kann ich aber nicht, wenn alles hintereinander angewendet wird und ich die Zeitzonen- und DST-Einstellungen Deines Systems nicht kenne.2021-01-05T01:18:37 hajUm uns zu verwirren?
Nein. Sondern um festzustellen, mit welchem Code was raus kommt. Wir sind doch hier im Moment im Labor oder nicht? Verstehe dich gerade nicht so richtig. Fühle ich da etwas Verärgerung bei dir?
2021-01-05T08:42:41 biancaJa, da scheiden sich möglicherweise die Geister. Nach meiner Lesart der alten Artikel (2003!) macht Strawberry Perl es so, wie ich es für richtig halte und der Fehler liegt irgendwo anders.Aktuell weiß ich, dass es in Strawberry anders läuft als ich mir wünschte...
2021-01-05T08:42:41 biancaWenn Du ein System hast, bei dem Du die Systemzeit ändern kannst, dann schreibe ein Programm, das alle halbe Stunde eine Datei mit fortlaufend nummerierten Dateinamen erstellt und lasse das während der Zeitumstellung von Sommerzeit auf Winterzeit laufen - und dann prüfe, was stat Dir für die Liste liefert. Mein Windows-Notebook steht grade woanders (Serenia), ich werde so einen Test machen, wenn die reale Zeitumstellung passiert.Was soll ich tun/testen/schreiben?
2021-01-05T08:42:41 biancaSorry, Bianca, das ist nicht die Doku, die ich verlinkt habe. Du zitierst aus Date::Calc für Localtime (großes L!), ich meine die Perl-Funktion localtime. Meines Wissens war letzte System, in dem diese Information nicht verfügbar war, Perl 5.004 auf MS-DOS.2021-01-05T01:18:37 hajLaut Dokumentation:
Quote-1 ist "true" bei Perl. Wenn Du -1 von 1 unterscheiden musst, dann ist das Glücksspiel. In welcher Situation bekommst Du -1?$isdst is true if the specified time occurs during Daylight Saving Time, false otherwise.
Bekomme ich nicht sondern steht in der selben Doku bei Localtime([time]):
QuoteThe daylight savings time flag ("$dst") will be "-1" if this information is not available on your system, "0" for no daylight savings time (i.e., winter time) and "1" when daylight savings time is in effect.
2021-01-05T08:42:41 biancaHier kommt mit rsync eine weitere Fehlerquelle ins Spiel... ich habe so langsam den Verdacht, dass Du ein rsync-Problem mit Perl-Mitteln "reparieren" willst.2021-01-05T01:18:37 hajIn der Umstellungsnacht wird die lokale Zeit um eine Stunde zurückgedreht. stat liefert, wenn's korrekt implementiert ist, die Anzahl an Sekunden seit 1. Januar 1970 UTC, und läuft einfach weiter. Lokale Zeiten von 02:00 bis 03:00 gibt es in der Umstellungsnacht zweimal, die sind 3600 stat-Sekunden auseinander.
Wie schon Raubtier geantwortet: das macht die andere rsync Seite auch. Dann matcht es wieder. Mit welchem Ergebnis es matcht spielt keine Rolle.
2021-01-05T08:42:41 biancaHm. Net::FTP ist ein FTP-Client und kein Server. Läuft der Server vielleicht unter Windows und hat seine eigenen DST-Fehler?Die andere Seite ist ein FTP-Server mittels Net::FTP der es "richtig" macht, daher ist hier nur die lokale Seite zu korrigieren gewesen.
2021-01-05T08:42:41 biancaWenn ich sauer wäre, würde ich einfach nicht mehr antworten. Aber ich finde das eigentlich eine der schönen Eigenschaften dieses Forums, dass hier auch "einfachere" Fragen gestellt und beantwortet werden.Vielen vielen Dank auch nochmal für deine Hilfe! Und bitte nicht sauer sein über meine Doofheit. Ich habe mir das alles eher schlecht als recht selbst angeeignet. Aber es läuft - meistens :)
2021-01-05T08:42:41 biancaTesten geht am einfachsten in der Sommerzeit: Auf jedem beteiligten System zur gleichen Zeit eine Datei anlegen, mit dem eingebauten stat die Daten notieren... und dann die Dateien mit rsync oder Net::FTP hin-und herkopieren und beobachten, ob und wie sich die stat-Ausgaben ändern. Ansonsten: Wo immer möglich, localtime durch gmtime ersetzen.Ich setze gelöst und stehe - wie gesagt - für weitere Tests und Analysen gern zur Verfügung.
2021-01-05T11:53:52 hajIm Labor bemühe ich mich, Fehler zu isolieren und Experimente nachvollziehbar zu machen. Das kann ich aber nicht, wenn alles hintereinander angewendet wird und ich die Zeitzonen- und DST-Einstellungen Deines Systems nicht kenne.
2021-01-05T11:53:52 hajJa, da scheiden sich möglicherweise die Geister. Nach meiner Lesart der alten Artikel (2003!) macht Strawberry Perl es so, wie ich es für richtig halte und der Fehler liegt irgendwo anders.
2021-01-05T11:53:52 hajWenn Du ein System hast, bei dem Du die Systemzeit ändern kannst, dann schreibe ein Programm, das alle halbe Stunde eine Datei mit fortlaufend nummerierten Dateinamen erstellt und lasse das während der Zeitumstellung von Sommerzeit auf Winterzeit laufen - und dann prüfe, was stat Dir für die Liste liefert. Mein Windows-Notebook steht grade woanders (Serenia), ich werde so einen Test machen, wenn die reale Zeitumstellung passiert.
2021-01-05T11:53:52 hajSorry, Bianca, das ist nicht die Doku, die ich verlinkt habe. Du zitierst aus Date::Calc für Localtime (großes L!), ich meine die Perl-Funktion localtime.
2021-01-05T11:53:52 hajMeines Wissens war letzte System, in dem diese Information nicht verfügbar war, Perl 5.004 auf MS-DOS.
2021-01-05T11:53:52 hajHier kommt mit rsync eine weitere Fehlerquelle ins Spiel... ich habe so langsam den Verdacht, dass Du ein rsync-Problem mit Perl-Mitteln "reparieren" willst.
2021-01-05T11:53:52 hajLäuft der Server vielleicht unter Windows und hat seine eigenen DST-Fehler?
2021-01-05T11:53:52 hajAber ich finde das eigentlich eine der schönen Eigenschaften dieses Forums, dass hier auch "einfachere" Fragen gestellt und beantwortet werden.
2021-01-05T11:53:52 hajAnsonsten: Wo immer möglich, localtime durch gmtime ersetzen.
2021-01-07T08:06:30 biancaJa, der Test schreibt Dateien. Aber dabei erzeugt das System die Zeitstempel, die Du mit stat abfragen kannst, auch ohne während der Tests wach zu sein. Wenn alles richtig läuft, dann sollten die Zeitstempel sauber aufsteigend sein. Der Windows-Fehler in den C-Bibliotheken, sorgt(e) dafür, dass es beim Übergang zur Sommerzeit einen "Sprung" in den Zeitstempeln gibt. Win32::UTCFileTime "korrigiert" das. Auf Systemen, die bei stat korrekte, d.h. auf UTC basierende Werte liefern, macht das Modul aus richtigen Zeitstempeln falsche. Wenn Du das vor der Sommerzeit-Umstellung testen willst, dann musst Du die Systemzeit umstellen.2021-01-05T11:53:52 hajWarum muss ich dafür die Systemzeit änderbar haben? Wie ich diesen Test verstehe ändert er die Zeit nicht sondern schreibt nur Dateien?Wenn Du ein System hast, bei dem Du die Systemzeit ändern kannst, dann schreibe ein Programm, das alle halbe Stunde eine Datei mit fortlaufend nummerierten Dateinamen erstellt und lasse das während der Zeitumstellung von Sommerzeit auf Winterzeit laufen - und dann prüfe, was stat Dir für die Liste liefert.[...]
2021-01-07T08:06:30 biancaGenau. Und in Deinem Testprogramm hast Du localtime benutzt.Jetzt sehe ich das Missverständnis!
localtime hat auch ein Flag!
2021-01-07T08:06:30 biancaDamit meine ich, dass der Wert -1 bei Date::Calc::Localtime anno 2021 nicht mehr auftreten dürfte, und Perls eingebautes localtime mindestens seit Version 5.8.8 davon ausgeht, dass der Wert verfügbar ist.2021-01-05T11:53:52 hajMeines Wissens war letzte System, in dem diese Information nicht verfügbar war, Perl 5.004 auf MS-DOS.
Was meinst du hiermit?
2021-01-07T08:06:30 biancaDa haben wir dann auch unterschiedliche Meinungen. Richtig ist für mich vor allem, die zeitliche Abfolge von Dateien richtig hinzukriegen, und das geht nur, wenn alle die gleiche Zeitbasis haben und es keine "Sprünge in die Vergangenheit" gibt.[...] (richtig ist für mich die Uhrzeit, die am Wirkungsort des Scripts ist)
2021-01-07T08:06:30 biancaSommerzeit als Fehlerquelle ausschliessen, genau. Das hat aber mit "Ignorieren" nichts zu tun. Ich stimme raubtier zu:2021-01-05T11:53:52 hajAnsonsten: Wo immer möglich, localtime durch gmtime ersetzen.
Neee lieber nicht. Das hatte ich schon ganz am Anfang ausgeschlossen, weil damit gar nichts mehr passt. Ich verstehe aber, worauf du hinaus willst. Sommerzeit als Fehlerquelle ausschließen durch Ignorieren. Darüber denke ich tatsächlich nach aber ich weiß noch nicht, welche Querschläger das verursacht.
QuoteWenn Du aus dieser Hölle rauswillst, solltest Du danach streben, localtime zu eliminieren.Sobald man mir irgendwas anderem als UTC rechnet, ist man in der Hölle.
2021-01-07T13:24:18 hajQuoteWenn Du aus dieser Hölle rauswillst, solltest Du danach streben, localtime zu eliminieren.Sobald man mir irgendwas anderem als UTC rechnet, ist man in der Hölle.
2021-01-05T18:56:46 LinuxerAn welchen und wie vielen Stellen brauchst Du eigentlich die korrigierten Zeitstempel?
2021-01-05T18:56:46 LinuxerAus #use Win32::UTCFileTime qw(:globally); lässt sich vermuten, dass das auch so im produktiven Code steht.
2021-01-05T18:56:46 LinuxerOhne das :globally sollte es die Funktionen nur in dem Package überschreiben, wo es auch eingebunden wird.
Damit müsste es dann (theoretisch) in Deinem/Deinen Modul(en), wo es benötigt (und jeweils eingebunden) wird, zur Verfügung stehen und andere Module wie Archive::Zip dann die originalen Funktionen benutzen können.
2021-01-02T10:53:58 hajDer Hinweis in Win32::UTCFileTime auf die Perl-Version 5.33 ist noch ein bisschen Zukunftsmusik: Die "ungeraden" Versionen sind Entwicklerversionen, freigegeben wird das also erst mit Perl 5.34, wohl im Sommer 2021. Dann kann man Perl auch mit alten Versionen von VS bauen.
QuoteThe times returned by stat() and lstat() are no longer incorrect across Daylight Savings Time adjustments. [GH #6080].
2021-05-21T15:29:47 hajEntgegen meiner Behauptung tritt das Problem wohl doch mit allen C-Libraries unter Windows auf. Da lag ich einfach falsch und bitte um Vergebung.
2021-05-21T15:29:47 hajaber dann sollte dieser 21 Jahre alte Fehler so langsam aus der Welt getilgt werden können.
2021-05-21T15:29:47 hajDas wird auch Zeit.Es wird noch ein bisschen dauern, bis die Strawberry-Distribution für diese Perl-Version gebaut ist, aber dann sollte dieser 21 Jahre alte Fehler so langsam aus der Welt getilgt werden können.