sizelist - das AT Tool ;-)

Skeeve

Pomme d'or
Registriert
26.10.05
Beiträge
3.120
Screib doch mal sizelist in ruby. Nicht, weil ich Dich ärgern will, sondern weil mich das wirklich interessiert. Naja... Und was die Komplexität bei Änderungen "tief unten" angeht, da tun sich die Programmiersprachen alle nichts. Für mich alten Sack ist objektorientierte Programmierung z.B. immer noch etwas, daß sich mir nicht ganz erschließt. Ich habe jetzt 26 Jahre prozedural programmiert. Das ist einfach drin.
 

tfc

Ontario
Registriert
21.07.07
Beiträge
348
Kann ich mal machen.

Das mit der Objektorientierung ist natürlich so eine Sache, da hast Du Recht. Es ist viel besser, sofort objektorientiert programmieren zu lernen, wenn man komplett neu einsteigt, als prozedural einzusteigen.
Wer sich auf Prozedurale Denkweisen eingeschossen hat, der bekommt leichte Probleme beim Umdenken. Das steht so in jedem Lehrbuch, weil es stimmt.
 
  • Like
Reaktionen: 1 Person

tfc

Ontario
Registriert
21.07.07
Beiträge
348
Okay, habe jetzt nicht ewig lang getestet, da das ja jetzt nur ne Beispiel-Implementierung in Ruby ist, aber das bisherige Ergebnis sieht so aus:

Code:
#!/usr/bin/ruby -w

class FSItemSize
  def initialize(path, depth=0)
    @depth = depth
    @path  = path
    @itemName = path.gsub(/^.*\//, '')
    if isDir then
      @childArray = []
      ordnerInhalt = Dir.new(@path)
      ordnerInhalt.each { |file|
        if file !~ /^\.{1,2}$/ then # alles, nur nicht ".", ".."
          subPath = (ordnerInhalt.path + "/" + file).sub(/\/{2}/, "/")
          @childArray.push(FSItemSize.new(subPath, @depth+1)) unless File.symlink?(subPath)
        end
      }
    end
  end

  def isDir
    true if File.directory?(@path)
  end

  def isFile
    true if !isDir
  end

  def getSize(sum=false)
    case $unit.upcase
    when "MB", "M"
      faktor = (1024)**-1
    when "GB", "G"
      faktor = ((1024)**-1)**2
    else # ungültig oder Standard: Kilobyte
      faktor = 1
    end
    if sum then
      size=0
      @childArray.each { |child|
        size += child.getSize(child.isDir ? true : false)
      }
    else
      size = (File.size(@path) * faktor)
    end
    if faktor != 1 then
      size = (size.to_f*100).round/100.0
    end
    size
  end

  def to_s
    if isFile || ($depth <= @depth && ($depth != -1)) then
      (isDir ? "d " : "f ") + getSize((($depth <= @depth) && ($depth != -1) && isDir) ? true : false).to_s + $unit + "    \t" + (" " * (@depth)).to_s + @path + "\n"
    else
      sumString = ""
      @childArray.each { |child| sumString= sumString + child.to_s }
      sumString
    end
  end
end

$path = File.directory?(ARGV[0]) ? ARGV[0] : "."
$depth = -1
$unit = "kb"
ARGV.each { |param|
    $depth = /(\d+)$/.match(param).to_s.to_i if param =~ /^--depth=(\d.+)$/
    $unit = /[kKmMgG][bB]$/.match(param).to_i if param =~ /^--unit=[kKmMgG][bB]$/
}
if ARGV.size >0 then
  firstDir = FSItemSize.new($path)
  puts firstDir.to_s
else
  puts "Usage: rubydu.rb <dir> [--depth=n] [--unit=<kb|mb|gb>]" unless ARGV.size >0
end

Habe keine Fremdmodule eingebunden, sondern alles selbstgebastelt. Das aus dem Grunde, dass ich bisher nur das OSX-Modul kenne und ein paar von Ruby on Rails.
 
  • Like
Reaktionen: Skeeve

IceHouse

Ribston Pepping
Registriert
30.09.04
Beiträge
297
Mit sizelist kann man sich einen Überblick über die Größe von Vereichnissen verschaffen. Dabei kann man festlegen, bis zu welcher Tiefe man Informationen benötigt (--maxdepth) und was die Minimalgrößen sind, die man zu sehen bekommen möchte (--minsize).
Viele Wege fuehren nach Rom. Ich nutze seit vielen Monden - ncdu » NCurses Disk Usage

Gruss von IceHouse
 

Anhänge

  • ncdu.jpg
    ncdu.jpg
    77,6 KB · Aufrufe: 121

Hobbes_

Gast
Das mit der Objektorientierung ist natürlich so eine Sache, da hast Du Recht. Es ist viel besser, sofort objektorientiert programmieren zu lernen, wenn man komplett neu einsteigt, als prozedural einzusteigen.
Wer sich auf Prozedurale Denkweisen eingeschossen hat, der bekommt leichte Probleme beim Umdenken. Das steht so in jedem Lehrbuch, weil es stimmt.

Da kann ich nur voll zustimmen. Ich gehöre auch noch zur alten Garde der Prozeduralen. Dies war schon ein Riesenfortschritt zum Spaghetticode früher. Auch die modulare Methode brachte wieder einiges Umdenken, wobei dies nicht nennenswert war.

Ich gebe zu, dass meine ersten Gehversuche in objektorientierten Programmen eher wie prozedurale Programme ausschauten. Vielleicht erschliessen sich immer noch nicht alle Geheimnisse, insbesondere die verschiedenen objektorientierten Sprachen auch sehr unterschiedlich ausgestaltete Unterstützung bezüglich Objekten anbieten (es wird besser).

Doch gerade für grössere Projekte mit zahlreichen Programmierern mit unterschiedlichen Aufgaben bietet der objektorientierte Approach m.E. schon klare Vorteile. Es ist vollkommen egal, wie die Dinge innerhalb der Objekte gelöst werden. Ich muss einzig wissen, wie ich es zur Ausführung einer bestimmten Aufgabe anstossen kann. Dennoch ist das ganze nur eine Abstraktionsebene. Letztlich wird eh alles in eine Folge von Befehlen übersetzt.

Selbstverständlich ersetzt auch der objektorienteirte Ansatz nicht ein vorheriges Durchdenken des Projektes, so dass die Schnittstellen bzw. eben die Objekte mit ihren Fähigkeiten klug gewählt werden. Man kann sowohl prozedural als auch objektorientiert ein kluges Design kreieren oder konzeptlos mal einfach starten. Es wird auch so immer elegantere Programme und weniger elegante Hacks geben.

just my 2 cents