CSS Framework

Apaan nih oooooooomm..... ???

http://centage.peruste.net/

Semoga bermanfaat.

Web Designer

http://www.spinxwebdesign.com

Design Form CSS Online

Mau design form CSS Online ?

Nih linknya, mainkan cuy !!!!
http://www.formstylegenerator.com/

Semoga bermanfaat.

Simple CSS — A Free CSS Authoring Tool

http://www.hostm.com/simplecss-download.m

http://www.zurb.com/playground

Main main ke ZURB PLayground

http://www.zurb.com/playground

Semoga bermanfaat.

CSS Positioning 101

If you’re a front end developer or a designer who likes to code, CSS-based layouts are at the very core of your work. In what might be a refresher for some, or even an “a-ha!” for others, let’s look at the CSS position property to see how we can use it to create standards-compliant, table-free CSS layouts.

Position is everything

CSS positioning is often misunderstood. Sometimes, in a bug-fixing fury, we apply different position values to a given selector until we get one that works. This is a tedious process that can work for a time, but it behooves us to know why specifying something like position: relative can fix your layout bug. My hope is that we can learn the position property’s values and behaviors, and most importantly, how a value can affect your markup. The CSS specification offers us five position properties: static, relative, absolute, fixed, and inherit. Each property serves a specific purpose. Understanding that purpose is the key to mastering CSS-based layouts.

Get with the flow

First, let’s take a step back to recognize the world we’re working in. Much like our real world, in CSS, we work within boundaries. In CSS, this boundary is called the normal flow. According to the CSS 2.1 spec:

Boxes in the normal flow belong to a formatting context, which may be block or inline, but not both simultaneously. Block boxes participate in a block formatting context. Inline boxes participate in an inline formatting context.

Think of a “box,” as described by the spec as a wooden block—not unlike the ones you played with as a young whippersnapper. Now, think of the normal flow as a law similar to the law of gravity. The normal flow of the document is how your elements stack one on top of each other, from the top down, in the order in which they appear in your markup. You may remember stacking alphabet blocks into giant towers: The normal flow is no different than those wooden blocks bound by the law of gravity. As a child, you had one block on top of another; in your markup, you have one element after another. What you couldn’t do as a child, however, was give those blocks properties that could defy the law of gravity. All of the sudden, CSS seems a lot cooler than those alphabet blocks.

Static and relative—nothing new here

The static and relative position properties behave like your childhood blocks—they stack as you would expect. Note that static is the default position value of an element, should you fail to apply any other value. If you have three statically positioned elements in your code, they will stack one on top of the next, as you might expect. Let’s take a look at an example with three elements, all with a position value of static:

#box_1 {
position: static;
width: 200px;
height: 200px;
background: #ee3e64;
}

#box_2 {
position: static;
width: 200px;
height: 200px;
background: #44accf;
}

#box_3 {
position: static;
width: 200px;
height: 200px;
background: #b7d84b;
}

In example A, you can see three elements stacked like a simple tower. Fascinating, isn’t it? This is block building 101. Congratulations!

You can use the static value for simple, single-column layouts where each element must sit on top of the next one. If you want to start shifting those elements around using offset properties such as top, right, bottom, and left, you’re out of luck. These properties are unavailable to a static element. In fact, a static element can’t even create a new coordinate system for child elements. Wait. What? You lost me at coordinate system. Roger that, Roger. Let’s explain using the relative value.

Relatively positioned elements behave just like statically positioned elements; they play well with others, stack nicely, and don’t cause a ruckus. Hard to believe, right? Take a look at our previous example. This time, we’ve applied the relative value:

#box_1 {
position: relative;
width: 200px;
height: 200px;
background: #ee3e64;
}

#box_2 {
position: relative;
width: 200px;
height: 200px;
background: #44accf;
}

#box_3 {
position: relative;
width: 200px;
height: 200px;
background: #b7d84b;
}

Example B proves that relatively positioned elements behave exactly the same way as statically positioned elements. What you may not know is that elements with a relative position value are like Clark Kent—they hide far greater powers than their static siblings.

For starters, we can adjust a relatively positioned element with offset properties: top, right, bottom, and left. Using the markup from our previous example, let’s add an offset position to #box_2:

#box_2 {
position: relative;
left: 200px;
width: 200px;
height: 200px;
background: #44accf;
}

Example C shows this relative positioning in action. Our three blocks are stacked up nicely, but this time the blue block (#box_2) is pushed out 200 pixels from the left. This is where we start to bend the law of gravity to our will. The blue block is still in the flow of the document—elements are stacking one on top of the other—but notice the green block (#box_3) on the bottom. It’s sitting underneath the blue block, even though the blue block isn’t directly above it. When you use the offset property to shift a relatively positioned element, it doesn’t affect the element(s) that follow. The green box is still positioned as if the blue box were in its non-offset position. Try that with your alphabet block tower.

Creating a coordinate system for child elements is another one of the relative positioning property’s super powers. A coordinate system is a reference point for offset properties. Recall in example C, our blue block (#box_2) is not sitting inside of any other elements, so the coordinate system it’s using to offset itself 200 pixels from the left is the document itself. If we place the #box_2 element inside of #box_1, we’ll get a different result, as #box_2 will position itself relative to the coordinate system from #box_1. For the next example, we won’t change any CSS, we’ll adjust our HTML to move #box_2 inside of #box_1:

Example D shows our new markup. Because of the new coordinate system, the blue block measures its offset 200 pixels from the left of the red block (#box_1) instead of the document. This practice is more common with elements set to position: absolute—the way you wish you could have built towers when you were younger.

Absolute—anywhere, anytime

If the relative value acts like Superman, then the absolute value mirrors Inception—a place where you design your own world. Unlike the static and relative values, an absolutely positioned element is removed from the normal flow. This means you can put it anywhere, and it won’t affect or be affected by any other element in the flow. Think of it as an element with a giant strip of velcro on its back. Just tell it where to stick and it sticks. Exactly like the relative value, absolutely positioned elements respond to offset properties for positioning. You can set an element to top: 100px and left: 200px; and that element will sit exactly 100px from the top and 200px from the left of the document. Let’s look at an example using four elements:

#box_1 {
position: absolute;
top: 0;
left: 0;
width: 200px;
height: 200px;
background: #ee3e64;
}
#box_2 {
position: absolute;
top: 0;
right: 0;
width: 200px;
height: 200px;
background: #44accf;
}
#box_3 {
position: absolute;
bottom: 0;
left: 0;
width: 200px;
height: 200px;
background: #b7d84b;
}
#box_4 {
position: absolute;
bottom: 0;
right: 0;
width: 200px;
height: 200px;
background: #ebde52;
}

Example E shows four boxes, each in a corner of the browser window. Since we set each box’s position value to absolute, we’ve essentially velcroed a box to each corner of our browser window. As you resize the browser, those boxes will stay in their respective corners. If you shrink the browser window so that the boxes overlap, you’ll notice that there is no interaction at all—that’s because they’re out of the document’s normal flow.

Just like relative elements, absolute elements create a new coordinate system for child elements. Example F extends Example E, with an orange element set inside each box. Notice the offset coordinates are in respect to each parent element.

Not to be outdone by other position property values, the absolute value offers some really cool functionality using the offset property. Use two or all four offset properties, and you can stretch an element without defining any width or height—it’s bound only by its parent element or the document itself. Let’s see it in action. Consider the following code:

#box_a {
position: absolute;
top: 10px;
right: 10px;
bottom: 10px;
left: 10px;
background: red;
}
#box_b {
position: absolute;
top: 20px;
right: 20px;
bottom: 20px;
left: 20px;
background: white;
}

In example G we’ve created a border offset 10 pixels by the document, and it’s entirely fluid as the document resize—all with absolute positioning and offsets. In another example, we can create a two-column layout that fills the entire height of the document. Here is the CSS:

#box_1 {
position: absolute;
top: 0;
right: 20%;
bottom: 0;
left: 0;
background: #ee3e64;
}

#box_2 {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 80%;
background: #b7d84b;
}

Example H shows a full-screen, two-column layout. While this likely isn’t the best approach to a two-column layout, it still shows the power the absolute value holds. Using some creative thinking you can find several useful applications for position: absolute. Similar tricks use only a single offset value. For example:

#box_1 {
width: 200px;
height: 200px;
background: #ee3e64;
}
#box_2 {
position: absolute;
left: 100px;
width: 200px;
height: 200px;
background: #44accf;
}

In example H2, focus on the blue block (#box_2). Notice how I use only one offset, left: 100px;. This allows the #box_2 element to maintain its top edge and still shift 100 pixels to the left. If we applied a second offset to the top, we would see that our blue block (#box_2) is pulled to the top of the document. See that here, in example H3:

#box_2 {
position: absolute;
top: 0;
left: 100px;
width: 200px;
height: 200px;
background: #44accf;
}

Fixed—always there

An element with position: fixed shares all the rules of an absolutely positioned element, except that the viewport (browser/device window) positions the fixed element, as opposed to any parent element. Additionally, a fixed element does not scroll with the document. It stays, well...fixed. Let’s look at an example:

#box_2 {
position: fixed;
bottom: 0;
left: 0;
right: 0;
}

Example I shows a footer with some copyright text in it as a fixed element. As you scroll, notice that it doesn’t move. Notice that the left and right offset properties are set to zero. Since the fixed value behaves similar to the absolute value, we can stretch the width of the element to fit the viewport while fixing the element to the bottom using bottom: 0;. Use caution with the fixed value: Support in older browsers is spotty at best. For example, older versions of Internet Explorer render fixed elements as static elements. And, you now know that static elements don’t behave like fixed elements, right? If you do plan to use fixed elements in a layout, there are several solutions that can help make your element behave properly in browsers that don’t support the fixed value.

Inherit—Something for nothing

As I mentioned at the beginning of this article, there are five values available to the position property. The fifth value is inherit. It works as the name implies: The element inherits the value of its parent element. Typically, position property elements do not naturally inherit their parent’s values—the static value is assigned if no position value is given. Ultimately, you can type inherit or the parent element’s value and get the same result.

In action

All this talk and no action. Let’s take a look at a real-world example website that uses all the position values. Example J shows a typical website layout with a header, navigation, content, and footer. Let’s walk through each element, discuss its position property, and why we chose that property.

Let’s start with our #container element. This is simply the containing element that I’m using to center our content within the viewport. The #nav element is the first element within our #container element. No position property is assigned to the #nav element, so by default, it’s set to static. This is fine: We don’t need to do anything to offset this element, or create any new coordinate systems with it. We will need to do that with #content on our next element, so for that element, we’ve applied a position property of relative.

Since we’re not using any offsets here, the position value has no real influence on the #content element, but we placed it there to create a new coordinate system for the #callout element. Our #callout element is set to position: absolute, and since its parent element, #content is set to relative, the offset properties we’re using on #callout are based off the coordinates created by #content. The #callout element uses a negative 80px pixel offset on the right to pull the element outside of its containing parent element. Additionally, I’ve used one of the cooler features of the absolute value on our #callout element: by setting the top and bottom offsets to 100px, I’ve stretched the #callout element to the full height of the document minus the 100px offset on top and bottom.

Since the #callout element has an absolute value, it does not affect other elements. Therefore, we need to add some padding to the #content element to keep our paragraphs from disappearing beneath it. Setting the padding on the right of #content to 250px keeps our content in full view for our users. To bring up the rear, we’ve added a footer with a fixed position to keep it fixed to the bottom of the page. As we scroll, our footer stays in place. Just as we added padding to the #content to keep our paragraphs from disappearing under it, we need to do the same for the #footer element as it is a sibling of the absolute value. Adding 60px to the #content element’s bottom padding ensures that we can scroll the entire document and not miss any text that would normally be hidden under the #footer element.

Now we have a nice, simple layout with navigation, some content, a callout area, and a footer using static, relative, absolute, and fixed elements. Since we’re using the fixed value in this layout, we should apply some techniques to make sure that older browsers still respect our design.

Conclusion

With the position property’s power, you can accomplish many a layout with confidence and success. Thankfully, 80% of the position property values have excellent support in both modern and older browsers. The fixed value is the one that you should watch out for. Understanding the core of these property values gives you a solid CSS-based layout foundation, limited only by your imagination. Hopefully, your days of guessing position values in a last-minute bug fix frenzy are now over.

Pure CSS GUI icons (experimental)

An experiment that uses pseudo-elements to create 84 simple GUI icons using CSS and semantic HTML. Shared as an exercise in creative problem solving and working within constraints. This is not a “production ready” CSS icon set.

Demo: Pure CSS GUI icons

Known support: Firefox 3.5+, Safari 5+, Chrome 5+, Opera 10.6+.

An exercise in constraint

Several months ago I was experimenting with the creation of common GUI icons with CSS. The HTML is very simple and it relies on CSS pseudo-elements rather than extraneous HTML elements. The technical aspects of this exercise might be of interest to others, so I’ve decided to share it.

Pseudo-elements provide many possibilities to developers interested in writing semantic HTML. If you’re looking for practical uses of pseudo-elements, this experiment gave me the idea for the technique used to create Multiple Backgrounds and Borders with CSS 2.1. But these GUI icons were a technical exercise.

Example code

The technique behind this experiment is an expansion of the basic shape-creation that was used to make Pure CSS speech bubbles. Some of these GUI icons can only be created in browsers that support CSS3 transforms.

The HTML is a basic unordered list of links.

  
Power
  
Play
  
Stop
  
Pause

Each icon uses its own set of styles. For example, the key parts of the CSS responsible for the “expand” icon are as follows:

.expand a:before {
  content:"";
  position:absolute;
  top:50%;
  left:1px;
  width:5px;
  height:0;
  border-width:7px 7px 0;
  border-style:solid;
  border-color:transparent #c55500;
  margin-top:-4px;
  /* css3 */
  -webkit-transform:rotate(-45deg);
  -moz-transform:rotate(-45deg);
  -o-transform:rotate(-45deg);
  transform:rotate(-45deg);
}

.expand a:after {
  content:"";
  position:absolute;
  top:50%;
  left:5px;
  width:8px;
  height:8px;
  border-width:3px 0 0 3px;
  border-style:solid;
  border-color:#c55500;
  margin-top:-6px;
}

.expand a:hover:before,
.expand a:focus:before,
.expand a:active:before {
  border-color:transparent #730800;
}

.expand a:hover:after,
.expand a:focus:after,
.expand a:active:after {
  border-color:#730800;
}

The demo page contains a full set of user interaction and media player control icons, as well as other common icons. For now, several icons actually require more than one element as CSS 2.1 only specifies 2 pseudo-elements per element that can contain generated content. The CSS3 Generated and Replaced Content Module allows for an unlimited number of pseudo-elements but has yet to be fully implemented in any modern browser.

Mozilla Confirms an App Store Is on the Way

Along with its audited financial statements indicating a revenue increase of 34 percent last year, Mozilla late last week also published a "State of Mozilla" report providing a glimpse at what the organization is planning for the future.

Firefox for Android is one part of those future plans, of course, and will be released "in a few months," according to the report.

Even more intriguing, though, is the company's confirmation that it's planning what it calls an "Open Web App ecosystem"--also known, in other words, as a platform-independent app store.

Device-Independent

"The current app model has traits that threaten some of the characteristics that have made the Web so vibrant a platform, particularly in the mobile space," Mozilla explained in its report.

Specifically, "apps are often device specific and platform specific," it said. "Information we create in an application is stuck in that application and / or that platform. One doesn't join a unified whole as one can with the Web. App-related information isn't generally linkable or findable. In addition, developers often need to get permission from one or more gatekeepers to reach people--from a network operator, a device manufacturer, a ‘store' operator. Similarly, consumers must go through these filters to access new functionality."

As a way to remedy such problems, Mozilla has designed a prototype of an Open Web App ecosystem, it says, noting that "this includes a system design, technical documentation and examples of what such a system would look like and work like." A video on YouTube offers further explanation.

HTML5, CSS and Javascript

Taking inspiration from the success of Apple's App Store, of course, Google has been working on its own Chrome Web Store as well. Mozilla also mentioned similar plans back in May.

"Supporting the needs of Web developers in their efforts to develop websites and apps that aren't bound to a specific browser and work across the Web is core to Mozilla's public benefit mission," Mozilla wrote back then.

Accordingly, an open Web app store should "exclusively host web applications based upon HTML5, CSS, Javascript and other widely-implemented open standards in modern web browsers - to avoid interoperability, portability and lock-in issues," it explained.

Such a store should also "ensure that discovery, distribution and fulfillment works across all modern browsers, wherever they run (including on mobile devices)" and "set forth editorial, security and quality review guidelines and processes that are transparent and provide for a level playing field."

Finally, an open Web app store should "respect individual privacy by not profiling and tracking individual user behavior beyond what's strictly necessary for distribution and fulfillment" and it should "be open and accessible to all app producers and app consumers," Mozilla wrote in May.

Too Many Apps For That?

App stores are becoming a ubiquitous part of the Internet; in addition to Apple's longstanding offering and the planned entries from Google and Mozilla, there are also app stores from Research In Motion for the Blackberry phone and from Microsoft for Windows Phone 7.

Then, too, there's Apple's Mac App Store for desktops and Google's assortment for Google TV, among others.

Few, however, can boast Mozilla's commitment to openness and open standards like HTML, CSS and JavaScript. Google's Chrome store notwithstanding, it seems to me that amid all these platform-specific offerings, a device-agnostic store is just what we need.

Prototype of an Open Web App Ecosystem

The open Web is a great platform for rich applications. It would be even better if it had additional capabilities to ease discovery, acquisition, installation and use of apps, while also enabling monetization for developers. We designed and built a prototype of a system for open Web apps: Apps built using HTML/CSS/JavaScript that work both on computers and mobile phones, have many of the characteristics that users find compelling about native apps and provide developers with open and flexible distribution options.

Today, we are releasing technical documentation of the proposed system and a developer preview prototype that allows you to install, manage and launch Web apps in any modern desktop or mobile browser (Firefox 3.6 and later, Firefox for mobile, Internet Explorer 8, Chrome 6, Safari 5, Opera 10 and WebKit mobile). This prototype provides a simple mechanism to support paid apps and authentication features to allow apps to log users in upon launch.

The design proposed here provides the following capabilities and enables a new category of what we call “Open Web Apps” — apps that are truly of the Web.

Open Web Apps:

• Are built using HTML, CSS and JavaScript.
• Can be “installed” to a dashboard within your mobile or desktop Web browser, or to your native OS desktop or mobile home screen.
• Work in all modern Web browsers, while enabling each browser to compete on app presentation, organization and management user interfaces.
• Support paid apps by means of an authorization model that uses existing identity systems like OpenID.
• Support portable purchases: An app purchased for one browser works in other browsers, and across multiple desktop and mobile platforms without repurchase.
• Can request access to one or more advanced and/or privacy-sensitive capabilities that they would like access to (like geolocation) which the system will mediate, giving the user the ability to opt-in to them if desired.
• Can be distributed by developers directly to users without any gatekeeper, and distributed through multiple stores, allowing stores to compete on customer service, price, policies, app discoverability, ratings, reviews and other attributes.
• Can receive notifications from the cloud.
• Support deep search across apps: Apps can implement an interface that enables the app container (generally the Web browser) to provide the user with a cross-app search experience that links deeply into any app that can satisfy the search.

Check out this demo to see more about our Open Web App prototype:

type="video/mp4" />

type="video/webm" />

type="video/ogg" />

data="http://www.youtube.com/v/iBFVrmyald4">
value="http://www.youtube.com/v/iBFVrmyald4" />

Please join us in exploring this Open Web App concept. Head over to the Mozilla Labs forum, leave a comment here and follow the Mozilla Labs blog for updates. As with everything Mozilla does, we’re developing this prototype and design for the public benefit in the open and we look forward to making this concept a reality.

Phone Makers, Software Vendors Push Web-based Apps

Companies including Mozilla, Opera Software, Palm and Sony Ericsson are trying to accelerate the use of Web standards when developing applications for smartphones.

Similar Articles:

• Palm Preps Tablet-friendly Application Framework
• 
  Mozilla Concept Phone Is a Glimpse of the Future
• 
  Palm Pre Is the Most Open Mobile Platform on the Market
• 
  Bad Apps Hurt Brand Names
• Cloud Sherpas Nabs Funds for Google Apps Tools, Services
• Yahoo Calls for Widget TV Developers

Using HTML, CSS (Cascading Style Sheets) and JavaScript to develop applications that run in the browser holds the promise of applications that work on different platforms, making life easier for both developers and users. Developers can write an application once and users can switch to a new phone based on a different OS and still keep all of their applications, according to Norwegian browser company Opera.

For this vision to become a reality, developers need easy-to-use tools, and in that space a lot of things are happening.

Sony Ericsson has made a tool called WebSDK Packager open source, it said in a blog post Tuesday. The WebSDK Packager is a good fit for developers with expertise in HTML, CSS and JavaScript who are adept at creating Web applications but are not familiar with the complexities of the mobile environment, according to Sony Ericsson.

On Saturday, Hewlett-Packard demonstrated Enyo, an upcoming framework for webOS, which is used on Palm smartphones, at its webOS Developer Day in New York. Enyo is designed to make it easier to develop applications for smartphones and tablets at the same time, according to HP.

Today, good development tools are only the first step. The ability for developers to make money off their applications is also a very important driver. Recently, Mozilla announced a prototype of what it calls "an Open Web App ecosystem", a system that aims to ease discovery, installation and use of applications based on HTML, CSS and JavaScript, while also enabling developers to make money via multiple applications stores. There is no official launch date yet, but "we look forward to making this concept a reality," Mozilla said.

It isn't just established companies that are making the Web vision a reality on smartphones. Sony Ericsson's WebSDK Packager tool is based on the PhoneGap open source framework, which was created by Nitobi.

Earlier this month, Nitobi announced the beta of PhoneGap Build, a cloud-based tool that allows developers to write applications using HTML, CSS and JavaScript, upload their apps to PhoneGap Build, and get back applications that work natively on smartphones based on Android, webOS, Symbian and the BlackBerry OS, and soon on iOS, Windows Mobile, MeeGo and Bada.

The tool will be free for open source projects; pricing details for commercial applications will be announced as the public launch nears.

However, Nitobi's hope is that what the company is doing today on PhoneGap will eventually be folded into the browser, according to Brian LeRoux, chief software architect at Nitobi, who took part in a panel discussion on cross-platform development at HP's developer day.

For the browser to take over, applications need to offer the same experience as native applications and browsers will have to be compatible with each other.

The point when that becomes a reality is close, according to Charles Jolley, creator of the SproutCore open source framework, who also took part in the panel discussion.

Ex-Apple employee Jolley has also founded Strobe, whose goal is to make SproutCore easier for developers to use.

Compatibility between different browsers is not the issue, thanks to the fact that they are all based on Webkit, and the differences that do exist are going away, according to Jolley. However, smartphones are still very memory and resource constrained and, historically, browsers have not been geared to working in that type of environment. But that is also changing, he said.

CSS in the cloud

http://eu.techcrunch.com/2010/11/25/buildorpro-wants-to-bring-htmlcss-editing-to-the-cloud-we-have-invites/

CSS Link

http://www.zurb.com/playground

Koleksi CSS Cheat

http://www.1stwebdesigner.com/resources/css-cheat-sheets-designers/

Masukkan gambar ke web

Gitu deh coba memasukkan gambar ke web.
asd;fk a
sdf
asdf
a
sdf

as
df
as
df

as
d asldjf asldfj laskdf as
df asdflk asdf
asdf asdf aasdf asdf asdf
asdf asdf asdf asdf asdf asdf
asdf
asd
fa
sd
f
as
df

as
df

as
df

as
df

asd
f

asd
f
as
d
f

asd
f

asd
f

as
df

a
sd
f
a
s
df

as
d
f
a
sdf

asdf asdf

scroll button

http://sorgalla.com/projects/jcarousel

free template website & css

http://opensourcetemplates.org/
http://www.freelayoutsworld.com/free-layouts/
http://www.freecsstemplates.org/css-templates/

Menu Website

http://www.smartmenus.org
http://apycom.com/menus/7-lime.html
http://www.brothercake.com/scripts/listmenu/

Image Slider

http://gmarwaha.com/jquery/jcarousellite/

Ajax Wizard

http://thecodemine.org

jqModal

http://dev.iceburg.net/jquery/jqModal/#examples

ajax dialog box

http://www.dottony.com/30-useful-ajax-lightbox-and-modal-dialog-solutions/

Info Website Tool

http://churchco.de/development/frameworks/page/2/

Learning Cron by Example

If you are using a Linux system and want to schedule a task to run in the future you will probably need to know cron. Cron is much like Window’s Scheduled Tasks. The only difference is that cron is conifgured by a simple text file. Although, that text file to the untrained looks very complicated. Many people rely cron task generators to do the work but I hope that after this guide you will be able to make your own tasks without the use of a generator.

Now obvisouly cron is very dependent and sensitive to the time. If you want accurate results from cron you are going to want to setup your computer to sync its clock via NTP. For now if you don’t have that configured you can use this command to get up to date temporarily:

As root:

ntpdate pool.ntp.org
Editing Cron


There are more than one way to edit the cron config files; however many of them require you to restart the service. We don’t want to do that so here is a method to add a task to cron without having to restart the deamon. You will need to login to the user you wish to execute the command and type:

crontab -e

Here is the basic structure for cron.

m h dom mon dow command

m – Minutes
h – Hours (24 time)
dom – Day of the Month
mon – Month
dow – Day of the week
command – The command you want to run. This can contain spaces or point to a bash script.
Examples


Since many of you like to learn by example, I am going to give you pretty much every example I can think of. This should help you get going with cron.

*’s represent wildcards or any.
Under dow 0 and 7 are both Sunday.

10 * * * * echo “This command is run at 10 min past every hour”
22 7 * * * echo “This command is run daily at 7:22 am”
22 20 * * * echo “This command is run daily at 8:22 pm”
00 4 * * 0 echo “This command is run at 4 am every Sunday”
* 4 * * Sun echo “This is the same as the command above”
42 4 1 * * echo “This command is run 4:42 am every 1st of the month”
01 * 19 07 * echo “This command is run hourly on the 19th of July”

Using the ‘-’ allows us to specify ranges of days. I actually used the following entry recently to run a script at the end of the working day.
Execute at 5pm only on weekdays:
* 17 * * 1-5 /path/to/your/code

Using the ‘,’ allows us to specify intervals wihout having to have multiple entries in cron.
This would execute the ask on the 1st, the 10th, the 20th and on the 30th of each month, at 17:59PM.
59 17 1,10,20,30 * * /home/username/backupsite

Using the ‘/’ allows us to divide the day into chunks.
Here, the tasks is executed every 4 hours (24/6 =4).
59 */6 * * * /home/username/backupsite

Here is another example of using chunks of time and a range.
Every 20 mins between the hours or 9am and 5pm
*/20 9-17 * * * /path/to/your/code
Dealing with the Output


Sometimes when we execute a command with cron we want to see the results of our command. Other times we could care less. By default the output from cron gets mailed to the owner of the process, or the person specified in the MAILTO variable. Here are some ways we can change the handling of it.

Structure:

cmd | argument

Example of an email output. This will email the results of my command every 4 hours to user, ‘mark’.
59 */6 * * * /home/username/backupsite | mail -s "Subject of Mail" mark

If we don’t care about the output we can send it to nowhere (literally). For example purposes I will just display the cmd and not the entire cron entry.
cmd | /dev/null

Output to a text file and append it if it exists already.
cmd >> log.file

More information can be found in the man page of cron. For more information just type:

man cron