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

Groups > de.comp.os.unix.linux.misc > #136178 > unrolled thread

Alle Pakete mit apt show

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Alle Pakete mit apt show Patrick Rudin <taxi_bs@gmx.ch> - 2023-12-16 18:53 +0100
    Re: Alle Pakete mit apt show Christian Garbs <mitch@cgarbs.de> - 2023-12-16 20:27 +0000
      Re: Alle Pakete mit apt show Patrick Rudin <taxi_bs@gmx.ch> - 2023-12-17 11:12 +0100
        Re: Alle Pakete mit apt show Stefan Möding <Dec2023.5.kill-9@spamgourmet.com> - 2023-12-17 12:35 +0100
          Re: Alle Pakete mit apt show Patrick Rudin <taxi_bs@gmx.ch> - 2023-12-21 12:55 +0100
            Re: Alle Pakete mit apt show Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-12-21 14:26 +0000
              Re: Alle Pakete mit apt show Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-12-21 16:21 +0000
                Re: Alle Pakete mit apt show Stefan Möding <Dec2023.5.kill-9@spamgourmet.com> - 2023-12-21 17:30 +0100
                  Re: Alle Pakete mit apt show Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-12-21 16:40 +0000
                    Re: Alle Pakete mit apt show "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2023-12-22 12:59 +0100
                Re: Alle Pakete mit apt show Claus Reibenstein <creibens@gmail.com> - 2023-12-22 16:06 +0100
              Re: Alle Pakete mit apt show Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2023-12-21 21:29 +0100
                Re: Alle Pakete mit apt show Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-12-22 09:54 +0000
                Re: Alle Pakete mit apt show Claus Reibenstein <creibens@gmail.com> - 2023-12-22 16:12 +0100
            Re: Alle Pakete mit apt show "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2023-12-22 12:51 +0100
            Re: Alle Pakete mit apt show Marc Haber <mh+usenetspam1118@zugschl.us> - 2023-12-23 09:15 +0100
              Re: Alle Pakete mit apt show Stefan Möding <Dec2023.5.kill-9@spamgourmet.com> - 2023-12-23 09:29 +0100
                Re: Alle Pakete mit apt show Patrick Rudin <taxi_bs@gmx.ch> - 2023-12-31 17:53 +0100
              Re: Alle Pakete mit apt show Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2023-12-23 09:56 +0000
              Re: Alle Pakete mit apt show Patrick Rudin <taxi_bs@gmx.ch> - 2023-12-31 17:37 +0100
      Re: Alle Pakete mit apt show Thomas Noll <-_tn_-@web.de> - 2023-12-17 12:55 +0000

Page 1 of 2  [1] 2  Next page →

#136178 — Alle Pakete mit apt show

Ich hätte gerne den Output von apt show (im dcf-Format, das sind 
maschinenlesbare debian control files) für sämtliche Pakete.

Also sowas wie:
apt show gnome* > pakete.txt

Aber eben für alle Pakete. Alles auswählen mit * alleine geht nicht, 
kann man das irgendwie überlisten?

apt list kann ich hier nicht verwenden, weil ich gerne auch alle 
Abhängigkeiten drinhaben möchte...


Grüsse

Patrick

[toc] | [next] | [standalone]

#136183

Mahlzeit!

Patrick Rudin <taxi_bs@gmx.ch> wrote:

> Ich hätte gerne den Output von apt show (im dcf-Format, das sind 
> maschinenlesbare debian control files) für sämtliche Pakete.
> 
> Also sowas wie:
> apt show gnome* > pakete.txt
> 
> Aber eben für alle Pakete. Alles auswählen mit * alleine geht nicht, 
> kann man das irgendwie überlisten?

apt show ruft intern apt-cache show auf (bzw. tut das gleiche wie
apt-cache show).

Folgendes gibt hier eine seeeeehr lange Liste aus (deren Inhalt ich
nicht manuell überprüft habe):

$ apt-cache show '*'

Ähem:

$ apt show '*'

macht das gleiche.

Vermutlich hattest Du ein Quoting-Problem.  Das * wird von Deiner
Shell auf Dateinamen gematched.  Damit es unbeeinflusst bei apt oder
apt-cache ankommt, musst Du es quoten: '*' oder "*" oder \*

Gruß
Christian
-- 
....Christian.Garbs....................................https://www.cgarbs.de
Q:      Why do firemen wear red suspenders?
A:      To conform with departmental regulations concerning uniform dress.

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

#136194

Christian Garbs wrote:
> $ apt show '*'

Ah, vielen Dank, das funktioniert.

Diese Shell bringt mich irgendwann noch ins Grab...


Grüsse

Patrick

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

#136196

Patrick Rudin <taxi_bs@gmx.ch> writes:

> Christian Garbs wrote:
>> $ apt show '*'

> Ah, vielen Dank, das funktioniert.

> Diese Shell bringt mich irgendwann noch ins Grab...

Man muss sich nur verinnerlichen, dass die Wildcards * und ? von der Shell
ausgewertet werden.  Die Shell fügt an der Stelle dann die entsprechenden
Dateinamen ein.  Das Kommando sieht daher nur die Liste der resultierenden
Dateinamen und nicht die Wildcards.

Dein ursprüngliches Beispiel mit "gnome*" hat eher zufällig funktioniert,
weil da im Verzeichnis keine Datei vorhanden war, deren Name mit gnome
anfängt.  Nur in diesem Fall bekommt der Befehl dann nämlich doch den Text
mit der Wildcard als Parameter.

Also eigentlich ganz einfach.  Wenn man die auf das Muster passenden
Dateinamen(!) meint, dann die Wildcards ohne Quoting nutzen.  Wenn man
aber das Zeichen * oder ? an den Befehl übergeben möchte und es nicht um
vorhandene Dateien geht, dann mit Quoting (wie im Posting von Christian
gezeigt).

-- 
Stefan

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

#136353

Stefan Möding wrote:
> Dein ursprüngliches Beispiel mit "gnome*" hat eher zufällig funktioniert,
> weil da im Verzeichnis keine Datei vorhanden war, deren Name mit gnome
> anfängt.  Nur in diesem Fall bekommt der Befehl dann nämlich doch den Text
> mit der Wildcard als Parameter.

Genau solche Inkonsistenzen verwirren mich halt immer wieder grandios.

Lustigerweise habe ich neulich einen rant von jemandem gelesen, der 
offenbar schon über 15 Jahre R benutzt, und er beschwert sich, dass 
heute an Statistik-Seminaren der Unis kaum mehr "base-r" unterrichtet 
wird, sondern nur noch die darauf aufpfropfenden Erweiterungspakete wie 
etwa das tidyverse.

Ich hab mir dann nur gedacht: Kunststück. Ich meide base-r auch. Das 
neumodische Zeugs hingegen hat halt eine konsistente Syntax, teilweise 
kommen sogar hilfreiche Fehlermeldungen, alles lässt sich prima mit der 
Pipe kombinieren und erzeugt lesbaren Code.

Allerdings sind jetzt meine Monitore zu klein, um die Abhängigkeiten der 
Debian-Pakete in einem hübschen Netzwerk-Graphen darstellen zu können...


Grüsse

Patrick

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

#136354

Patrick Rudin <taxi_bs@gmx.ch> wrote:
> Stefan Möding wrote:
>> Dein ursprüngliches Beispiel mit "gnome*" hat eher zufällig funktioniert,
>> weil da im Verzeichnis keine Datei vorhanden war, deren Name mit gnome
>> anfängt.  Nur in diesem Fall bekommt der Befehl dann nämlich doch den Text
>> mit der Wildcard als Parameter.
> 
> Genau solche Inkonsistenzen verwirren mich halt immer wieder grandios.

Inkonsist ist das nur fuer denjenigen, der das Konzept der command line
exapansion der UNIX Shell nicht verstanden hat:
Nach einem ENTER expandiert bzw interpretiert die Shell Metazeichen 
* ? ( ) [ ] { } < > | ; $ & ` ' " ! ~ # \ SPACE TAB
bevor es das Kommando aufruft.
Das lernen meine Studenten bei mir in der zweiten Stunde :-)
Man sollte unbedingt wissen, was diese Zeichen bedeuten bzw bewirken.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

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

#136355

On Thu, 21 Dec 2023 15:26:05 Ulli Horlacher wrote:
> Patrick Rudin <taxi_bs@gmx.ch> wrote:
>> Stefan Möding wrote:
>>> Dein ursprüngliches Beispiel mit "gnome*" hat eher zufällig
>>> funktioniert, weil da im Verzeichnis keine Datei vorhanden war,
>>> deren Name mit gnome anfängt.  Nur in diesem Fall bekommt der
>>> Befehl dann nämlich doch den Text mit der Wildcard als
>>> Parameter.

>> Genau solche Inkonsistenzen verwirren mich halt immer wieder grandios.
 
> Inkonsist ist das nur fuer denjenigen, der das Konzept der command
> line exapansion der UNIX Shell nicht verstanden hat: [...]

Es ist konform zur Spezifikation, aber *konsistent* ist es nicht.
Konsistent wäre, wenn Wildcards ohne Quote nie bis zur Applikation
durchdringen würden, sondern immer von der Shell (ggf. halt in
"nichts") aufgelöst würden.

> Nach einem ENTER expandiert bzw interpretiert die Shell
> Metazeichen
> * ? ( ) [ ] { } < > | ; $ & ` ' " ! ~ # \ SPACE TAB
> bevor es das Kommando aufruft.

Aber halt nicht immer.

Weiss man, aber lästig ist es dennoch. Verwendest Du denn immer
Quotes, weil sich ein passendes File im aktuellen Verzeichnis
befinden *könnte*? Ich nicht, Faulheit siegt (meistens).

Servus,
   Stefan

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

Mehr als man erwartet. Stefan - prall und begehrlich.
(Sloganizer)

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

#136356

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> Konsistent wäre, wenn Wildcards ohne Quote nie bis zur Applikation
> durchdringen würden, sondern immer von der Shell (ggf. halt in
> "nichts") aufgelöst würden.

Das muss man dann der Bash anlasten.  Die ZSH hat eine Option, um bei
einer nicht funktionierenden Expansion einen Fehler zu werfen:

% echo foo*
zsh: no matches found: foo*

% unsetopt NOMATCH
% echo foo*
foo*

-- 
Stefan

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

#136358

On Thu, 21 Dec 2023 17:30:56 Stefan Möding wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>> Konsistent wäre, wenn Wildcards ohne Quote nie bis zur Applikation
>> durchdringen würden, sondern immer von der Shell (ggf. halt in
>> "nichts") aufgelöst würden.

> Das muss man dann der Bash anlasten.  Die ZSH hat eine Option, um bei
> einer nicht funktionierenden Expansion einen Fehler zu werfen:

> % echo foo*
> zsh: no matches found: foo*

Das geht mit der bash schon auch:

#v+
~$ echo foo*
foo*
~$ shopt -s failglob
~$ echo foo*
bash: no match: foo*
#v-

Nur: Wer kennt das schon, wer merkt sich all die nützlichen Optionen
für den Fall des Falles - und wer setzt sie dann auch?

Das Problem ist vermutlich, dass das Default-Verhalten *meistens*
sehr praktisch (für Dinge wie apt) ist, weil so gut wie nie
matchende Dateien im Verzeichnis sind und man daher zwei Zeichen
weniger tippen muss. Bis dann...

Servus,
   Stefan

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

Erregt bleibt erregt: Stefan für alle Fälle!
(Sloganizer)

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

#136372

On 2023-12-21 16:40, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:
> On Thu, 21 Dec 2023 17:30:56 Stefan Möding wrote:
>> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>>> Konsistent wäre, wenn Wildcards ohne Quote nie bis zur Applikation
>>> durchdringen würden, sondern immer von der Shell (ggf. halt in
>>> "nichts") aufgelöst würden.
>
>> Das muss man dann der Bash anlasten.  Die ZSH hat eine Option, um bei
>> einer nicht funktionierenden Expansion einen Fehler zu werfen:
>
>> % echo foo*
>> zsh: no matches found: foo*
>
> Das geht mit der bash schon auch:
>
> #v+
> ~$ echo foo*
> foo*
> ~$ shopt -s failglob
> ~$ echo foo*
> bash: no match: foo*
> #v-
>
> Nur: Wer kennt das schon, wer merkt sich all die nützlichen Optionen
> für den Fall des Falles - und wer setzt sie dann auch?

Die muss man sich nicht merken. Die schreibt man einmal in die .zshrc,
.bashrc, etc. und denkt dann die nächsten 30 Jahre nicht mehr daran.

> Das Problem ist vermutlich, dass das Default-Verhalten *meistens*
> sehr praktisch (für Dinge wie apt) ist, weil so gut wie nie
> matchende Dateien im Verzeichnis sind und man daher zwei Zeichen
> weniger tippen muss.

Oder nur eines. Gut, wenn man jetzt die Zehntelsekunden, die mir das
über die Jahrzehnte gespart hätte, zusammenzählt, kommt vielleicht eine
erschreckend hohe Zahl heraus. Aber wenn das erst mal ins
Muskelgedächtnis übergegangen ist, ist das nicht spürbar langsamer. Und
es erspart das Nachdenken darüber, ob man escapen muss oder nicht
(kostet auch wertvolle Zehntelsekunden ;-)) und im Zweifelsfall
unangenehme Überraschungen.

        hp

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

#136375

Stefan Froehlich schrieb am 21.12.2023 um 17:21:

> On Thu, 21 Dec 2023 15:26:05 Ulli Horlacher wrote:
>
>> Inkonsist ist das nur fuer denjenigen, der das Konzept der command
>> line exapansion der UNIX Shell nicht verstanden hat: [...]
>
> Es ist konform zur Spezifikation, aber *konsistent* ist es nicht.

Was ist daran inkonsistent? Wenn es keine passende Datei gibt, wird
einfach der Wildcard unverändert weitergegeben. Es ist dann Sache des
aufgerufenen Befehls, damit umzugehen. Beispielsweise würden Befehle wie
"rm", "cp", "ls", "cat" sich darüber beschweren, dass keine solche Datei
existiert, was durchaus im Sinne des Erfinders ist.

> Konsistent wäre, wenn Wildcards ohne Quote nie bis zur Applikation
> durchdringen würden, sondern immer von der Shell (ggf. halt in
> "nichts") aufgelöst würden.

Mit "nichts" würdest Du jegliche mögliche Fehlerbehandlung aushebeln.

> Verwendest Du denn immer
> Quotes, weil sich ein passendes File im aktuellen Verzeichnis
> befinden *könnte*?

Aber natürlich. Habe ich schließlich so gelernt und Jahrzehnte lang
praktiziert.

> Ich nicht, Faulheit siegt (meistens).

Du bist eben kein Entwickler :-)

Gruß
Claus

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

#136361

Hallo Ulli,

Du schriebst am Thu, 21 Dec 2023 14:26:05 +0000 (UTC):

> Nach einem ENTER expandiert bzw interpretiert die Shell Metazeichen 
> * ? ( ) [ ] { } < > | ; $ & ` ' " ! ~ # \ SPACE TAB
> bevor es das Kommando aufruft.

Da fehlt aber noch der ":" (Doppelpunkt, engl. "colon").

-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

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

#136368

Sieghard Schicktanz <Sieghard.Schicktanz@schs.de> wrote:
> Hallo Ulli,
> 
> Du schriebst am Thu, 21 Dec 2023 14:26:05 +0000 (UTC):
> 
>> Nach einem ENTER expandiert bzw interpretiert die Shell Metazeichen 
>> * ? ( ) [ ] { } < > | ; $ & ` ' " ! ~ # \ SPACE TAB
>> bevor es das Kommando aufruft.
> 
> Da fehlt aber noch der ":" (Doppelpunkt, engl. "colon").

Nein.

framstag@fex:~: echo :
:

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

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

#136376

Sieghard Schicktanz schrieb am 21.12.2023 um 21:29:

> Hallo Ulli,
> 
> Du schriebst am Thu, 21 Dec 2023 14:26:05 +0000 (UTC):

Mach da mal _eine_ Einleitungszeile draus.

>> Nach einem ENTER expandiert bzw interpretiert die Shell Metazeichen 
>> * ? ( ) [ ] { } < > | ; $ & ` ' " ! ~ # \ SPACE TAB
>> bevor es das Kommando aufruft.
>
> Da fehlt aber noch der ":" (Doppelpunkt, engl. "colon").

Seit wann ist ":" ein Metazeichen? Welche Bedeutung hat er für die Shell?

Gruß
Claus

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

#136371

On 2023-12-21 11:55, Patrick Rudin <taxi_bs@gmx.ch> wrote:
> Stefan Möding wrote:
>> Dein ursprüngliches Beispiel mit "gnome*" hat eher zufällig funktioniert,
>> weil da im Verzeichnis keine Datei vorhanden war, deren Name mit gnome
>> anfängt.  Nur in diesem Fall bekommt der Befehl dann nämlich doch den Text
>> mit der Wildcard als Parameter.
>
> Genau solche Inkonsistenzen verwirren mich halt immer wieder grandios.

In der zsh (und ich glaube auch in der bash) kann man einstellen, dass
Wildcards, die keine Files matchen, als Fehler behandelt werden und
nicht kommentarlos an die Applikation weitergereicht werden. Das hat den
Vorteil, dass man sich sehr schnell angewöhnt, Wildcards, die nicht von
der Shell aufgelöst werden sollen, immer zu escapen.

        hp

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

#136391

Patrick Rudin <taxi_bs@gmx.ch> wrote:
>Lustigerweise habe ich neulich einen rant von jemandem gelesen, der 
>offenbar schon über 15 Jahre R benutzt, und er beschwert sich, dass 
>heute an Statistik-Seminaren der Unis kaum mehr "base-r" unterrichtet 
>wird, sondern nur noch die darauf aufpfropfenden Erweiterungspakete wie 
>etwa das tidyverse.
>
>Ich hab mir dann nur gedacht: Kunststück. Ich meide base-r auch. Das 
>neumodische Zeugs hingegen hat halt eine konsistente Syntax, teilweise 
>kommen sogar hilfreiche Fehlermeldungen, alles lässt sich prima mit der 
>Pipe kombinieren und erzeugt lesbaren Code.

Warum erinnert mich das an TeX und LaTeX?

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

#136395

Marc Haber <mh+usenetspam1118@zugschl.us> writes:

> Warum erinnert mich das an TeX und LaTeX?

Ich sehe das aus einem anderen Blickwinkel.

Hin und wieder schafft es jemand, ein persönliches Problem so umfassend zu
lösen, dass auch andere Leute die Anstrengung auf sich nehmen, um damit
arbeiten zu können.  Und dann ist da soviel Weitsicht im Spiel, dass
beispielsweise durch eine Macro-Sprache eine Erweiterbarkeit gegeben ist,
so dass das Ganze auch Jahrzehnte später noch nützlich ist.  So was
beeindruckt mich.

Standing on the shoulders of giants.

-- 
Stefan

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

#136643

Stefan Möding wrote:
> Hin und wieder schafft es jemand, ein persönliches Problem so umfassend zu
> lösen, dass auch andere Leute die Anstrengung auf sich nehmen, um damit
> arbeiten zu können.  Und dann ist da soviel Weitsicht im Spiel, dass
> beispielsweise durch eine Macro-Sprache eine Erweiterbarkeit gegeben ist,
> so dass das Ganze auch Jahrzehnte später noch nützlich ist.  So was
> beeindruckt mich.

Zweifellos. Ich würde mir ab und an halt nur wünschen, dass von den 
Genies bei der Gestaltung der Syntax auch daran gedacht würde, dass auch 
Normalsterbliche die Tools benützen können...


Grüsse

Patrick

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

#136396

On Sat, 23 Dec 2023 09:15:14 Marc Haber wrote:
> Patrick Rudin <taxi_bs@gmx.ch> wrote:
>>Kunststück. Ich meide base-r auch. Das neumodische Zeugs hingegen
>>hat halt eine konsistente Syntax, teilweise kommen sogar
>>hilfreiche Fehlermeldungen, alles lässt sich prima mit der Pipe
>>kombinieren und erzeugt lesbaren Code.

> Warum erinnert mich das an TeX und LaTeX?

Was ist LaTeX? Ich kenne nur Koma-Script :-)

Servus,
   Stefan

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

Mit der Sympathie des Verführers! Stefan, so hydriert...
(Sloganizer)

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

#136642

Marc Haber wrote:
> Patrick Rudin <taxi_bs@gmx.ch> wrote:
>> Ich hab mir dann nur gedacht: Kunststück. Ich meide base-r auch. Das
>> neumodische Zeugs hingegen hat halt eine konsistente Syntax, teilweise
>> kommen sogar hilfreiche Fehlermeldungen, alles lässt sich prima mit der
>> Pipe kombinieren und erzeugt lesbaren Code.
> 
> Warum erinnert mich das an TeX und LaTeX?

Ich hab _ein_ Latex-Template, das ich für meine Briefe benutze. Daran 
schraube ich nicht rum, weil ich sofort die Übersicht verlieren würde.

Wobei Lubridate (aus dem Tidyverse) auch nicht so wirklich konsistent ist:

test <- tibble(datum=ymd_hms("2023-12-31-17:29:33")

  test %>% mutate(jahr=year(datum), monat=month(datum), tag=day(datum), 
stunde=hour(datum), minute=minute(datum), sekunde=second(datum), 
wotag=wday(datum), wochentag=wday(datum, label=T, abbr=T))

# A tibble: 1 × 9
   datum                jahr monat   tag stunde minute sekunde wotag 
wochentag
   <dttm>              <dbl> <dbl> <int>  <int>  <int>   <dbl> <dbl> 
<ord>
1 2023-12-31 17:29:33  2023    12    31     17     29      33     1 So 



Also: Das Jahr ist ein double, der Monat auch, der Tag ein Integer, die 
Minute ebenso, die Sekunde ein Double und der Wochentag als Nummer ein 
Double. Dass in einem Statistikpaket der abgekürzte Wochentag ein Factor 
ist, verstehe ich ja noch halbwegs, aber der Rest ist schon schräg...


Grüsse

Patrick

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web