Posts Tagged instalacja

Instalacja aplikacji na karcie SD w systemie Android

Telefon G1 ma niestety niewielką ilość pamięci dostępnej do instalacji aplikacji. Już po zainstalowaniu kilku większych pojawia się problem z brakiem pamięci RAM. Niestety, standardowo w systemie Android nie ma możliwości instalacji aplikacji na karcie SD (o ci aż się prosi). Dopiero wersja 2.2 może to zmienić, istnieje możliwość przeniesienie czy tez instalacji na karcie aplikacji obsługujących to.

Na szczęście system operacyjny Android jest systemem otwartym, istnieje kilka jego modyfikacji, które rozszerzają jego podstawowe możliwości. I tak, jeżeli dysponujemy:

  • system operacyjny pochodzący od CyanogenMod, w moim przypadku jest to Android w wersji 2.1 (CyanogenMod 5.0.8)
  • dostęp do użytkownika root
  • karta SD

Krok 1: Partycjonowanie karty SD

Zanim zaczniemy instalować aplikacje na karcie, należy najpierw utworzyć dla nich miejsce. Można to zrobić tworząc partycję typu EXT na karcie.

UWAGA:

Partycjonowanie karty spowoduje utratę wszystkich danych jakie są na niej zapisane. Także warto zrobić wcześniej jej kopię bezpieczeństwa.

Partycjonowanie karty odbywa się w trybie [cic]Recovery[/cci]. Można do nie go wejść, jeżeli uruchamiamy telefon trzymając naciśnięty klawisz Home. Po takim uruchomieniu powinno ukazać się menu, i jedną z pozycji będzie Partition sdcard.

Tryb Recovery - wybór partycjonowania karty

Tryb Recovery - wybór partycjonowania karty

Po wyborze pozycji partycjonowania, pojawią się kolejne pozycje, z których należy wybrać Partition SD:

Partycjonowanie karty

Partycjonowanie karty

W tym momencie będziemy musieli zdefiniować podział karty na partycję. Pierwszą definiowaną partycją będzie SWAP, należy podać jej wielkość (przy użyciu kulki). Następnie należy zdefiniować partycję typu EXT2, na niej będą trzymane instalowane aplikacje. Pozostała część karty zostanie przeznaczona na system plików VFAT i będzie używana jak standardowa karta SD.

Definicja partycji na karcie

Definicja partycji na karcie

Po utworzeniu partycji można jeszcze zmienić typa partycji z EXT2 na EXT4. Należy powrócić do menu Partition sdcard. Następnie najpierw wybrać pozycję SD:ext2 to ext3, a następnie SD:ext3 to ext4.

Teraz pozostaje już tylko uruchomić telefon.

Krok 2: Instalacja aplikacji na karcie

W przypadku korzystania z modu CyanogenMod nowa partycja EXT zostanie wykryta automatycznie i zamontowana w katalogu /sd-ext. Nie ma potrzeby dokonywania żadnych dodatkowych kroków związanych z montowaniem tego udziału dyskowego. W przypadku oryginalnego systemu Andorid (lub też pewnie innych modów) trzeba jeszcze zamontować w odpowiedni sposób tę partycję, aby dało się z niej uruchamiać aplikacje. Więcej informacji można znaleźć w artykułach do których linki znajdują się na końcu tego wpisu.

Po utworzeniu partycji na karcie SD i uruchomieniu telefonu pozostaje teraz włączyć jej obsługą przez system operacyjny. Można to zrobić uruchamiając Ustawienia->Aplikacje i zaznaczając opcję Apps2SD (opcja ta jest charakterystyczna dla CyanogenMod). Od tego momentu wszystkie nowo instalowane aplikacje będą zapisywane na karcie SD.

Opcja konfiguracyjna App2SD

Opcja konfiguracyjna App2SD

Istnieje także możliwość przeniesienia już zainstalowanych aplikacji na kartę SD. Można to zrobić poprzez wybranie Ustawienia->Aplikacje->Zarządzaj aplikacjami. Teraz należy wybrać aplikację, która ma zostać przeniesiona na kartę. Zostaną wyświetlone podstawowe informacje o aplikacji (m.in. miejsce instalacji i rozmiar). Powinien tam także znaleźć się przycisk Move. Wybranie go spowoduje przeniesienie aplikacji na kartę SD.

Przeniesienie aplikacji na kartę SD

Przeniesienie aplikacji na kartę SD

Nie zauważyłem żadnych różnic w pracy z aplikacjami zapisanymi na karcie SD, działają i zachowują się dokładnie tak jak w momencie instalacji w pamięci telefonu. Ale teraz mam już dożo więcej miejsca na instalację nowych aplikacji :).

Źródła

Tags: , , , , ,

Instalacja bazy danych Oracle XE 10g w 64 bitowym systemie Debian lub Ubuntu

Oracle udostępnia darmową wersję swojej bazy danych o nazwie Oracle XE 10g. Posiada ona szereg ograniczeń w stosunku do wersji komercyjnej, ale można jej zarówno używać w małych systemach oraz pozwala na zapoznanie się z samą bazą danych. Oracle udostępnia pakiety instalacyjne swojej bazy danych zarówno dla środowiska Red Hat jak i wywodzących się z Debiana. Niestety, są dostępne wersje tych pakietów tylko dla architektury 32 bitowej, co uniemożliwia przeprowadzenie prostej instalacji w środowisku 64 bitowym.

Na szczęście, nie będzie bardzo źle, wystarczy kilka dodatkowych kroków i powinno się udać.

Krok 1: Pobranie bazy danych

Bazę danych Oracle XE 10g można pobrać ze stron firmy Oracle: Oracle Database Software Downloads: Oracle Database 10g Release 2 (10.2.0.1). Należy zgodzić się tam na warunki licencji (należałoby także się z nią zapoznać) a następnie można pobrać odpowiednie pakiety z bazą danych.

Można także pobrać odpowiedni plik od razu z udostępnianego przez Oracle repozytorium dla Debiana: oracle-xe-universal_10.2.0.1-1.1_i386.deb.

$ wget http://oss.oracle.com/debian/dists/unstable/non-free/binary-i386/oracle-xe-universal_10.2.0.1-1.1_i386.deb

Próba instalacji tego pakietu w środowisku 64 bitowy skończy się takim komunikatem błędu:

# dpkg -i oracle-xe-universal_10.2.0.1-1.1_i386.deb
dpkg: błąd przetwarzania oracle-xe-universal_10.2.0.1-1.1_i386.deb (--install):
 architektura pakietu (i386) nie zgadza się z architekturą systemu (amd64)
Wystąpiły błędy podczas przetwarzania:
 oracle-xe-universal_10.2.0.1-1.1_i386.deb

Krok 2: Instalacja dodatkowych pakietów

Należy zainstalować w systemie także obsługę bibliotek 32 bitowych:

# aptitude install libc6-i386

Pakiet ten może już być zainstalowany.

Dodatkowo należy zainstalować pakiet bc (także może już znajdować się w systemie):

# aptitude install bc

Należy także zainstalować 32 bitową wersję pakietu libaio.

Dla Ubuntu Lucid najnowszą wersję pakietu można pobrać ze strony Download Page for libaio1_0.3.107-3ubuntu2_i386.deb on Intel x86 machines.

Dla Debiana Lenny najnowszą wersję pakietu można pobrać ze strony Download Page for libaio1_0.3.107-3_i386.deb on Intel x86 machines.

Instalacja tego pakietu jest możliwa przy użyciu takiej komendy (powoduje instalację pakietu i ignorowanie architektury):

# dpkg -i --force-architecture libaio1_*_i386.deb

Podczas instalacji zostanie wyświetlone ostrzeżenie o niezgodności architektury, ale nie powinny wystąpić inne problemy.

Krok 3: Instalacja Oracle XE 10g

Po niezbędnych krokach przygotowawczych czas na instalację samej bazy danych:

# sudo dpkg -i --force-architecture oracle-xe-universal_10.2.0.1-1.1_i386.deb

Po zainstalowaniu pakietu pozostaje go jeszcze skonfigurować przy użyciu polecenia:

# /etc/init.d/oracle-xe configure

Najpierw zostaniemy poproszeni o wskazanie portu HTTP, poprzez który będziemy mogli połączyć się z interfejsem do zarządzania bazą danych, domyślnie jest przyjmowany port 8080. W moim przypadku port ten często jest zajęty przez inne aplikacji, więc zmieniłem go na 8081:

Specify the HTTP port that will be used for Oracle Application Express [8080]:8081

Teraz należy podać domyślny port na którym będzie nasłuchiwała baza danych na przy chodzące połączenia z aplikacji, w przypadku Oracle jest to port 1521:

Specify a port that will be used for the database listener [1521]:

Należy podać hasła do konta administracyjnego:

Specify a password to be used for database accounts.  Note that the same
password will be used for SYS and SYSTEM.  Oracle recommends the use of
different passwords for each database account.  This can be done after
initial configuration:
Confirm the password:

Ostatnie pytanie pozwoli na podjęcie decyzji, czy Oracle ma startować podczas uruchamiania komputera.

Z tego co widzę w skryptach startowych, jeżeli wyłączymy tę opcję, to pozbędziemy się możliwości korzystania ze skryptu /etc/init.d/oracle-xe w celu zatrzymywania i startowania bazy danych (ręcznego, nie podczas uruchamiania systemu). Dlatego też proponuję tutaj zostawić odpowiedź y nawet w sytuacji, gdy nie chcemy aby baza danych startowała za każdym razem i po instalacji przeczytać punkt o 6.

Do you want Oracle Database 10g Express Edition to be started on boot (y/n) [y]:y

Nastąpi teraz konfiguracja bazy danych, po której powinna już działać. Pozostaje tylko połączyć się ze wskazanym adresem i zalogować do bazy danych.

Krok 4: Konfiguracja zmiennych środowiskowych

Można jeszcze dodać do ścieżki poleceń katalog z plikami wykonywalnymi Oracla.

Jeżeli jesteśmy jedynym użytkownikiem komputera, można je zdefiniować w pliku ~/.bashrc danego użytkownika. W przypadku gdy użytkowników jest kilku, warto utworzyć plik /etc/profile.d/oracle.sh. Plik ten będzie wczytywany przy logowaniu każdego użytkownika. Oczywiście, należy zwrócić uwagę odpowiednie uprawnienia do tego pliku:

# chmod 644 /etc/profile.d/oracle.sh

Zawartość pliku oracle.shlub też parametry, które należy dopisać w profilu danego użytkownika:

1
2
3
4
5
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_HOME
export ORACLE_SID=XE
export PATH

Pozostaje się teraz zalogować ponownie (lub wykonać plik w ramach sesji) aby zmienne zaczęły działać.

Krok 6: Zatrzymywanie i uruchamianie bazy danych Oracle XE 10g

Jeżeli baza danych ma nie być uruchamiana podczas startu systemu, najlepiej jest usunąć odpowiednie linki z katalogów rc?.d:

# rm /etc/rc?.d/S??oracle-xe

Uruchomienie serwera jest możliwe poprzez wydanie komendy:

# /etc/init.d/oracle-xe start

Zatrzymanie serwera natomiast następuje po użyciu polecenia:

# /etc/init.d/oracle-xe stop

Pozostałe opcje można zobaczyć po użyciu polecenie:

# /etc/init.d/oracle-xe
Usage: /etc/init.d/oracle-xe {start|stop|restart|force-reload|configure|status|enable|disable}

Po tych operacjach powinniśmy dysponować działającą bazą Oracle XE 10g w środowisku 64 bitowym.

Źródła

Tags: , ,

Typy aplikacji jakie można zainstalować w serwerze aplikacji JBoss

Każda aplikacja, która ma działać w ramach danego serwera JBoss musi zostać najpierw zainstalowana przez niego zainstalowana. Jest to możliwe na kilka sposobów:

  • można umieścić aplikację w katalogu deploy serwera;
  • można zainstalować aplikację przy użyciu polecenia twiddle;
  • można użyć konsoli administracyjnej;

Więcej informacji na temat instalacji aplikacji znajduje się w tym wpisie: Zarządzanie instalacją aplikacji w JBoss AS.

Formaty pakietów z aplikacjami

Instalowana aplikacja może zarówno być w formie archiwum jak i jak katalogu z plikami zapisanymi w odpowiedniej strukturze (archiwum to nic innego jak ten sam katalog skompresowany przy użyciu algorytmu ZIP). Każda z form ma swoje wady i zalety, ale nie różnią się one efektem. Zarówno w jednym jak i drugim przypadku pozwalają na instalację aplikacji.

W przypadku skompresowanego archiwum mamy do czynienia z pojedynczym plikiem, które dużo łatwiej przesłać czy też skopiować. W przypadku jego rozkompresowanej formy mamy do czynienia z setkami czy też często tysiącami plików. Trudniej w takim przypadku zarządzać taką aplikacją (nie można np. zainstalować jej przy pomocy konsoli administracyjnej), za istnieje możliwość modyfikacji pojedynczych plików (np. strony JSP) i następnie łatwe wymuszenie restartu aplikacji.

Odpowiedni wątek monitorujący pojawienia się (lub też usuniecie) aplikacji w katalogu deploy monitoruje czasy modyfikacji odpowiednich plików w archiwum. I tak, jeżeli zmienimy odpowiedni plik (w zależności od rodzaju aplikacji) to nastąpi automatyczne odinstalowanie wybranej aplikacji i jej ponowna instalacja.

Podstawowe deskryptory aplikacji
Typ aplikacji Plik deskryptora
WAR WEB-INF/web.xml
EAR META-INF/application.xml
SAR META-INF/jboss-service.xml
JAR META-INF/ejb-jar.xml
RAR META-INF/ra.xml

Typy aplikacji instalowanych przez JBossa

JBoss rozróżnia poszczególne typy aplikacji na podstawie końcówek ich nazw (uwaga, często jest to więcej niż rozszerzenie). Ponieważ każdy typ aplikacji spełnia inne funkcje w ramach infrastruktury, którą zapewnia serwer aplikacji istotne jest zachowanie odpowiedniej kolejności startowania tych aplikacji. I tak różnego rodzaje aplikacje usługowe musza zostać uruchomione przed aplikacjami biznesowymi, które mają z nich korzystać. Tak samo najpierw należy odpowiednio skonfigurować połączenia z bazą danych, zanim zaczną działać aplikacje z nich korzystające.

W poniżej tabeli znajdują się typy poszczególnych aplikacji wraz z ich krótkim omówieniem. Jednocześnie pozycja występowania na tej liście mówi o kolejności startu danej aplikacji.,

Końcówka nazwy Typ aplikacjia
.deployer
-deployer-beans.xml
Aplikacje, które pozwalają na instalację innych rodzajów aplikacji. W przypadku JBossa 5.1 znajdują się one w katalogu $JBOSS_HOME/server/PROFIL/deployers
aop
-aop.xml
Definicja aspektów stosowany do klas lub rozszerzenie czy też dodanie nowych funkcji do tych klas
.sar
-service.xml
Różnego rodzaju aplikacje usługowe, rozszerzające możliwości serwera aplikacji
-jboss-beans.xml Definicja obiektów POJO mikrokontenera
.rar Konfiguracja różnych zasobów
-ds.xml Definicja źródeł danych, używanych potem przez aplikacje w celu uzyskania dostępu do bazy danych
.har Definicja archiwum Hibernate, używanego do do dostępu do bazy danych przy użyciu Hibernate
.jar Zbiór komponentów EJB lub też po prostu biblioteka klas
.zip Serwer aplikacji sprawdzi zawartość archiwum i postara się rozpoznań typ aplikacji jaki się w nim znajduje. Potem zostanie ona zainstalowana jak aplikacja o odpowiednim typie.
.war Archiwum z aplikację webową, dostarczająca interfejs dostępny przez przeglądarkę lub też web service
.wsr Archiwum specyficzne dla JBossa, zawiera web service. Używany jeżeli dana aplikacja ma zostać zainstalowana po wszystkich archiwach WAR.
.ear Aplikacja Java EE, zawiera EJB, aplikacja WAR oraz inne biblioteki klas
.bsh Definicja usługi przy użyciu powłoki bean shell
.last Tak oznaczone aplikacje będą instalowane jako ostatnie w ramach swojego typu

Aplikacje same w sobie mogą byc zagnieżdżone. I tak aplikacja typu EAR najczęściej składa się z szeregu plików JAR z logiką biznesową, z warstwy prezentacji WAR oraz różnych innych deskryptorów. W takim przypadku JBoss stara się odnaleźć te różne aplikacji i je w ramach głównej aplikacji zainstalować. Tutaj również ma zastosowanie taka sama kolejność instalacji aplikacji jak w tabeli powyżej.

Źródła

Tags: , , , ,

Automatyczna instalacja aplikacji znajdującej się poza katalogiem deploy

Domyślna konfiguracja serwera aplikacji JBoss automatycznie instaluje wszystkie aplikacje które znajdą się w katalogu deploy wybranego profilu. Może się jednak zdarzyć, że potrzebujemy instalować automatycznie zainstalować aplikację która znajduje się poza tym katalogiem (np. nie mamy dostępu do tego katalogu, jest to katalog współdzielony przez inne instancje czy też może z innych powodów).

Jednym ze sposób takiej instalacji jest użycie polecenia twiddle, tak jak jest to opisane tutaj: Zarządzanie instalacją aplikacji w JBoss AS. Taka instalacja jednak nie przetrwa restartu serwera, trzeba będzie odpowiednie polecenie wydawać po każdym uruchomieniu serwera lub aktualizacji aplikacji.

Innym sposobem jest wskazie w konfiguracji serwera dodatkowego katalogu, który będzie traktowany tak jak katalog deploy. Czyli w domyślnej konfiguracji wszystkie aplikacje (czy też pliki) będą automatycznie instalowane w serwerze aplikacji.

W przypadku serwera aplikacji JBoss wersji 5.1 odpowiedni należy modyfikacje wprowadzić w pliku conf/bootstrap/profile.xml. Plik ten znajduje się w wybranym profilu. Można tam znaleźć taką linię:

25
26
27
28
29
<property name="applicationURIs">
    <list elementClass="java.net.URI">
        <value>${jboss.server.home.url}deploy</value>
    </list>
</property>

Widać tutaj definicję podstawowego katalogu, który służy do instalacji aplikacji: ${jboss.server.home.url}deploy. Wystarczy teraz umieścić dodatkowy wpis określający nowy katalog i od tej pory JBoss powinien już go używać także do instalacji aplikacji. Ścieżkę dostępu należy podać w formie URI:

25
26
27
28
29
30
31
32
<property name="applicationURIs">
    <list elementClass="java.net.URI">
        <value>${jboss.server.home.url}deploy</value>

        <!-- Nowy katalog do skanowania -->
        <value>file:///nfs/applications</value>
    </list>
</property>

Źródła

Tags: , , , , ,

Zarządzanie instalacją aplikacji w JBoss AS

Jeżeli JBoss AS zostanie uruchomiony w domyślnej (default) konfiguracji to jest wstępnie skonfigurowany tak, że automatycznie instaluje wszelkie aplikacje jakie pojawią się w katalogu deploy. Podobnie, jeżeli jakąś aplikacja zostanie usunięta z tego katalogu, to automatycznie zostanie ona także odinstalowana z serwera. Zachowanie takie jest bardzo przydatne w momencie gdy tworzymy lub testujemy aplikację, ale niekoniecznie porządne na systemie produkcyjnym. Automatyczna instalacja aplikacji może się wiązać z takimi problemami jak:

  • ciągle jest uruchomiony specjalny wątek, który sprawdza czy nowa aplikacja nie pojawiła się w katalogu deploy;
  • trzeba pamiętać, że aktualizacja aplikacji wiąże się w w praktyce z usunięciem aplikacji z serwera i jej ponowną instalacją, więc jeżeli z jakiś powodów zaktualizujemy aplikację, nastąpi jej usunięcie, co w konsekwencji może przeszkodzić w pracy użytkownikom korzystającym z aplikacji;
  • przypadkowa (czy też nawet zamierzona) edycja plików deskryptora aplikacji także powoduje jej restart.

Konfiguracja skanowania zmian w katalogu deploy

Za konfigurację mechanizmu skanującego zmiany w katalogu deploy odpowiada klasa HDScanner. Konfiguracja usługi znajduje się w pliku deploy/hdscanner-jboss-beans.xml:

10
11
12
13
14
15
16
17
18
19
<!-- Hotdeployment of applications -->
<bean name="HDScanner" class="org.jboss.system.server.profileservice.hotdeploy.HDScanner">
    <property name="deployer"><inject bean="ProfileServiceDeployer"/></property>
    <property name="profileService"><inject bean="ProfileService"/></property>
    <property name="scanPeriod">5000</property>
    <property name="scanThreadName">HDScanner</property>
<!--
   <property name="scanEnabled">false</property>
-->
</bean>

Interesujące parametry:

  • scanPeriod
    Czas odstępu pomiędzy poszczególnymi skanowaniami wyrażona w milisekundach, domyślna wartość to 5000, czyli 5 sekund.
  • scanThreadName
    Nazwa wątka, który skanuje katalogu, domyślna wartość HDScanner. Można zmienić na inną wartość, jeżeli monitorujemy działające wątki serwera.
  • scanEnabled
    Zmienna określająca, czy skanowanie powinno być włączone (wartość true) czy też nie (wartość false). W domyślnej konfiguracji nie występuje w pliku XML. Próba dodanie jej z wartością true powoduje, że serwer wyrzuca szereg wyjątków:

    23:34:18,727 ERROR [AbstractKernelController] Error installing to Configured: name=HDScanner state=Instantiated
    java.lang.RuntimeException: Error configuring property: scanEnabled for HDScanner
            at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
            at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
    ...

    Prawdopodobnie jest to spowodowane błędem Setting HDScanner’s scanEnabled Attribute to True via XML Results In NPE lub też Setting HDScanner’s scanEnabled Attribute to True via XML Results In NPE

Jak widać, nie da się po prostu włączyć odpowiedniego przełącznika i wyłączyć automatyczną instalację aplikacji. W związku z tym, należy usunąć z katalogu deploy plik hdscanner-jboss-beans.xml[.

Po tym kroku przestanie działać usługa odpowiedzialna za skanowanie katalogu deploy, więc zmiany w nim będą sprawdzane tylko podczas startu serwera aplikacji.

Ręczna instalacja aplikacji

Jeżeli jest wyłączone automatyczne skanowanie katalogu deploy a trzeba zainstalować jakąś aplikację, można użyć polecenia twiddle.sh za pomocą którego można wywołać ziarno MainDeployer, które odpowiada za instalację aplikacji:

  • deploy – instalacja wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" deploy "file:/ścieżka/do/pliku/do/instalacji"
  • undeploy – odinstalowanie wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" undeploy "file:/ścieżka/do/pliku/do/instalacji"
  • redeploy – przeinstalowanie wybranej aplikacji
    twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" redeploy "file:/ścieżka/do/pliku/do/instalacji"
  • hdscanner-jboss-beans.xml – ponowna instalacja skanowania
    1. Skopiuj plik hdscanner-jboss-beans.xml z powrotem do katalogu deploy.
    2. Wykonaj polecenie:
      twiddle.sh -s localhost -u UŻYTKOWNIK -p HASŁO invoke "jboss.system:service=MainDeployer" redeploy "file:/ścieżka/do/pliku/xml"

Co trzeba jeszcze zapamiętać:

  • serwera aplikacji musi mieć dostęp do wskazanego pliku
  • aplikacja do zainstalowania zostanie zainstalowana bezpośrednio, nie będzie ona kopiowania do katalogu deploy, zostanie ona od razu rozkompresowana do katalogu tmp
  • zainstalowane aplikacje nie będę ponownie uruchamiane po restarcie serwera (chyba że zostaną one umieszczone w katalogu deploy ręcznie.

Lista zainstalowanych aplikacji

Można uzyskać listę zainstalowanych aplikacji, przy pomocy polecenie twiddle:

twiddle.sh invoke jboss.deployment:flavor=URL,type=DeploymentScanner listDeployedURLs | sed -e 's/,/\n/g'

Domyślnie poszczególne ścieżki z aplikacji są oddzielone od siebie znakiem ‚,’, polecenie sed zmienia je na znak nowej linii.

Źródła

Tags: , , , , ,